Re: Questions about the -ENODEV judgment of PHYID

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Mon, Aug 04, 2025 at 05:22:55PM +0800, Kanglong Wang wrote:
> I hope you're having a great day.
> 
> When reading the code, I see that when phy_id is 0x1fffff, it is judged to
> be -ENODEV, but I don 't see this description in the IEEE 802.3 document.
> 
> I am writing to ask the following drivers/net/phy/phy_device.c file in the
> get_phy_c22_id function about phy_id judgment whether there is any other
> document basis ?
> 
> The commits are as follows:
> 
>         ee951005e95e net: phy: clean up get_phy_c22_id() invalid ID handling
>         48c543887bc5 net: phy: clean up get_phy_c45_ids() failure handling
>         e63062616df3 net: phy: clean up PHY ID reading         454a78d17845
> net: phy: clean up cortina workaround

Thanks for asking on the mailing list instead of emailing privately.

While there may not be anything in 802.3, the point of the code is to
detect whether there is actually a PHY present.

The MDIO data line is pulled high. If there is no response from a PHY,
then while the data is being read, the MDIO data line will remain high
and thus we read '1' bits. The result is that a register reads as
0xffff. As the PHY ID covers 32-bits across two registers, when we
assemble the PHY ID, a non-present PHY will read as 0xffffffff.

I can't say for certain why we ignore the top three bits of register 2.
My best guess is that there are systems which either sporadically
return random noise in those bits or similar, leading to false PHY
detection and systems that fail.

These seem to be the relevant commits:

6436cbcd735a ("phy: fix phy_id detection also for broken hardware.")
3ee82383f009 ("phy: fix phy address bug")

Commit 3ee82383f009 was definitely wrong, and introduced a bug where
non-present PHYs in properly functioning hardware would be detected.
Commit 6436cbcd735a happened a week later to fix this patch.

Sadly, it seems that the mailing list archives for netdev around this
time no longer exist (at least as far as Google is concerned) so I
suspect the context behind these two patches has been lost.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!