Re: [PATCH v5 net-next] net: phy: mediatek: support MT7530 PHYs on EN71221 MCM
From: Caleb James DeLisle
Date: Thu Sep 17 2026 - 17:00:32 EST
On 17/09/2026 21:21, Daniel Golle wrote:
On Thu, Sep 17, 2026 at 05:11:50PM +0200, Caleb James DeLisle wrote:
On 17/09/2026 16:48, Daniel Golle wrote:It's also fine for me like it is now, just a light preference, not
On Tue, Sep 15, 2026 at 02:01:29PM +0200, Caleb James DeLisle wrote:
On 15/09/2026 13:47, Daniel Golle wrote:I would have preferred to call genphy_match_phy_device() in your match
On Tue, Sep 15, 2026 at 11:34:27AM +0000, Caleb James DeLisle wrote:I suppose the latter is easier because then I don't have to re-think
@@ -135,6 +199,23 @@ static struct phy_driver mtk_gephy_driver[] = {I'd suggest to actually use phy_id and phy_id_mask assigned by the
*/
.config_intr = genphy_no_config_intr,
.handle_interrupt = genphy_handle_interrupt_no_ack,
+ .match_phy_device = mt7530_phy_match,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ .read_page = mtk_phy_read_page,
+ .write_page = mtk_phy_write_page,
+ },
+ {
+ PHY_ID_MATCH_EXACT(MTK_GPHY_ID_MT7530),
PHY_ID_MATCH_EXACT macro by calling genphy_match_phy_device() in your
match functions above instead of open-coding the ID match.
Or drop PHY_ID_MATCH_EXACT from *both* drivers.
mt7530_is_gphy() which would be lying if it wasn't actually checking ID is
MTK_GPHY_ID_MT7530.
functions instead of open-coding phy_id_compare() which is best
reached via genphy_match_phy_device() in this situation -- that would
express the code intent in the most obvious way imho.
I did it this way because the name mt7530_is_gphy() implies "Is this an
MT7530 gigabit PHY?" which if it doesn't match on MTK_GPHY_ID_MT7530 then
that's not what it does so there's a little bit more thought involved.
If I'd have known this was really your preference I'd have done that, but I
already just sent v6 so I guess I can send v7 tomorrow.
worth a resend just for that.
However, I'd also still like to see the OF parent walk replaced by
register evidence, which requires that you dump the registers more
than once to understand if any difference are things like counters or
temperature, or actually identify the PHY variant.
It can of course be that the actual silicon is really the exact same
MT7530 MCM as eg. on MT7623, just driven by a different clock
frequency and the observable register differences are things like
clock devidors -- if we manage to understand that and just apply the
resulting tuning accordingly, even better.
I just tried removing the remaining phy_write commands and it still seems to work. It seems that the thing that really made this driver not work on EcoNet was the EEE which Vladislav Karmanov removed in ccbe7540e4aad earlier this month. So at this point I guess I could send a patch which does nothing except check MII_ESTATUS & ESTATUS_1000_TFULL so it doesn't get confused with the FE driver.
I'm not sure if this is a good plan to deviate from what the vendor code was, but the values are not wildly different. If you think it's smart, I can send this and we'll see how it goes.
Thanks,
Caleb