[PATCH net-next] net: phy: mediatek: support MT7530 PHYs on EN71221 MCM

[Caleb James DeLisle]

On 10/09/2026 03:55, Daniel Golle wrote:
> On Thu, Sep 10, 2026 at 01:26:14AM +0200, Caleb James DeLisle wrote:
>> On 10/09/2026 01:02, Daniel Golle wrote:
>>> On Wed, Sep 09, 2026 at 09:32:50PM +0000, Caleb James DeLisle wrote:
>>>> The EcoNet EN751221 multi-chip module implementation of the MT7530
>>>> requires some additional configuration of the PHYs on startup.
>>>> The reason for this is not known, but it is possible that it has
>>>> to do with the fact that the EN751221 MCM implementation of the
>>>> MT7530 runs at an abnormal PLL frequency (362.5Mhz).
>>>>
>>>> Detect whether the MT7530 PHY is attached to the MDIO bus of an
>>>> EcoNet EN751221 switch and if so, apply the necessary register
>>>> updates.
>>>>
>>>> Co-developed-by: Matheus Sampaio Queiroga <srherobrine20 at gmail.com>
>>>> Signed-off-by: Matheus Sampaio Queiroga <srherobrine20 at gmail.com>
>>>> Signed-off-by: Caleb James DeLisle <cjd at cjdns.fr>
>>>> ---
>>>>    drivers/net/phy/mediatek/mtk-ge.c | 61 +++++++++++++++++++++++++++++++
>>>>    1 file changed, 61 insertions(+)
>>>>
>>>> diff --git a/drivers/net/phy/mediatek/mtk-ge.c b/drivers/net/phy/mediatek/mtk-ge.c
>>>> index 73d9b72f9d9e..42b06c40d703 100644
>>>> --- a/drivers/net/phy/mediatek/mtk-ge.c
>>>> +++ b/drivers/net/phy/mediatek/mtk-ge.c
>>>> [...]
>>>>    static int mt7530_phy_config_init(struct phy_device *phydev)
>>>>    {
>>>> +	int ret;
>>>> +
>>>> +	if (mt7530_phy_is_en751221_companion(phydev)) {
>>> Please introduce a `.match_phy_device` operation for both, actual
>>> MT7530 and EN751221, similar eg. to `ksz8051_match_phy_device` in
>>> micrel.c.
>> Sounds good, since this will certainly collide with
>> https://lore.kernel.org/netdev/20260827065930.2618729-2-cjd@cjdns.fr/ would
>> you prefer them in the same patch, or as a patch set? If you'd like I can do
>> this and the FE phy as a common patch set. Let me know what you prefer.
> I'd do it one driver at a time, starting with mtk-ge.c, already adding
> the .match_phy_device logic so it would also avoid binding the MT7530
> driver to an ECONET_FEPHY.
>
> The econet-fe-soc.c driver is much larger and may require more rounds
> to make all bots and humans happy, so I'd not have the independently
> useful mtk-ge.c changes depend on that.
Good point, so I can make mtk-ge so it won't interfere with "any future 
FE PHY with the same ID" with the understanding that this PHY is moving 
along at it's own pace.
>
> Dumping the PHY register space and comparing it with MT7530 could also
> help to indentify any better way than relying on the parent DT
> compatible which *is* a bit of a stretch (but could well be
> unavoidable, of course).

I'll give it a shot but I have low confidence in it because AFAIK this 
is actually a real MT7530 MCM just like MT7621 but it just happens to be 
clocked to a weird PLL frequency.


Thanks,

Caleb

>