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: <9393c232-06d8-464e-ac94-597eaeda2630@lunn.ch>
Date: Thu, 11 Sep 2025 14:58:32 +0200
From: Andrew Lunn <andrew@...n.ch>
To: yicongsrfy@....com
Cc: linux@...linux.org.uk, 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

> 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).

I would say the PHY driver is broken, or at least, not correctly
handling the situation. When the scan finds the PHY at address 0, the
PHY driver is probed, and it should look at the strapping and decided,
if the strapping has put the PHY at address 0, or its the broadcast
address being used. If it is the broadcast address, turn off broadcast
address, and return -ENODEV. phylib should then not create a PHY at
address 0. The scan will continue and find the PHY at its correct
address. Your problem then goes away, and phylib has a correct
representation of the hardware.

The harder bit is backwards compatibility. Are there DT files which
make use of the broadcast address, and disabling it will break them?

We have seen patches disabling broadcast, but i don't remember for
which PHY.

	Andrew