netdev - Re: [PATCH] net: phy: avoid config_init failure on unattached PHY during resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aMqILVD_F7Rm-mfx@shell.armlinux.org.uk>
Date: Wed, 17 Sep 2025 11:06:37 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: yicongsrfy@....com
Cc: andrew@...n.ch, davem@...emloft.net, edumazet@...gle.com,
	hkallweit1@...il.com, kuba@...nel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, pabeni@...hat.com, yicong@...inos.cn
Subject: Re: [PATCH] net: phy: avoid config_init failure on unattached PHY
 during resume

On Thu, Sep 11, 2025 at 07:25:25PM +0800, yicongsrfy@....com wrote:
> However, there is a particular scenario as follows:
> 
> Some PHY chips support two addresses, using address 0 as a broadcast address
> and address 1 as the hardware address. Both addresses respond to GMAC's MDIO
> read/write operations. As a result, during 'mdio_scan', both PHY addresses are
> detected, leading to the creation of two PHY device instances (for example,
> as in my previous email: xxxxmac_mii_bus-XXXX:00:00 and xxxxmac_mii_bus-XXXX:00:01).

IEEE 802.3 makes no provision for a broadcast address. Here is what it
says about the PHY address:

22.2.4.5.5 PHYAD (PHY Address)

The PHY Address is five bits, allowing 32 unique PHY addresses. The
first PHY address bit transmitted and received is the MSB of the
address. A PHY that is connected to the station management entity
via the mechanical interface defined in 22.6 shall always respond to
transactions addressed to PHY Address zero <00000>. A station
management entity that is attached to multiple PHYs must have prior
knowledge of the appropriate PHY Address for each PHY.

So, phylib code can't make any special exception for address zero.
We definitely have network adapters where their PHYs are at address
zero, so blocking that address will break them.

As for Andrew's suggestion, returning an error in the probe function
doesn't prevent the phy_device being created, and it will mean that
if a MAC driver attempts to attach to that instance, phylib will use
the generic PHY driver instead. So, this doesn't solve the problem.

I don't see that there is anything that a PHY driver can do to solve
this as the code currently stands, especially if the MAC driver is
coded to "use the lowest PHY address present on the MDIO bus" (which
in this case will be your vendor's idea of a broadcast address.)

I really don't think we should start adding hacks for this kind of
stuff into phylib's core - we can't know that PHY address 0 is a
duplicate of another address.

The only thing I can come up with is:

1. There must be a way to configure the PHY to disable its non-
   standard "broadcast MDIO address" to make it compliant with 802.3.
   I suggest that board firmware needs to set that to make the PHY
   compliant.

2. As a hard reset of the PHY will likely clear that setting, this is
   another nail in the coffin of PHY hard reset handling in the kernel
   which has been the cause of many issues. (Another nail in that
   coffin is that some MACs require the RX clock from the PHY to be
   running in order to properly reset.)

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