The RTL8365MB-VC PHYs are integrated into the switch and have no MMD registers of their own. What phylib accesses as MMD registers (EEE) actually lives in the switch's OCP registers; the realtek DSA driver maps those MMD requests onto OCP and exposes them over C45. For a C22 PHY, phy_read_mmd()/phy_write_mmd() would use C22 indirect-MMD, which this hardware does not implement. Point .read_mmd/.write_mmd at genphy_{read,write}_mmd_c45() so phylib's MMD accesses go over C45 to the DSA driver's mapping instead. Signed-off-by: Oleksij Rempel Reviewed-by: Andrew Lunn --- Anticipated reviewer questions: Q: .read_mmd/.write_mmd now use the C45 helpers, but the DSA user MDIO bus only gains .read_c45/.write_c45 in the next patch -- is this bisect-broken? A: No. Until then an MMD access returns -EOPNOTSUPP, but the only one that runs is the EEE-ability read in phy_probe(), which phylib ignores; probe, link and traffic are unaffected. ethtool --show-eee reports EEE unsupported here -- the same as before this series, since these ports gain EEE only in the next patch -- so it is not a regression. Verified on an RTL8365MB-VC. --- drivers/net/phy/realtek/realtek_main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c index 177b62a7b2d1..ad8017e91b4f 100644 --- a/drivers/net/phy/realtek/realtek_main.c +++ b/drivers/net/phy/realtek/realtek_main.c @@ -3388,6 +3388,8 @@ static struct phy_driver realtek_drvs[] = { }, { PHY_ID_MATCH_EXACT(0x001cc942), .name = "RTL8365MB-VC Gigabit Ethernet", + .read_mmd = genphy_read_mmd_c45, + .write_mmd = genphy_write_mmd_c45, /* Interrupt handling analogous to RTL8366RB */ .config_intr = genphy_no_config_intr, .handle_interrupt = genphy_handle_interrupt_no_ack, -- 2.47.3