linux-kernel - 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: <20250922015651.589429-1-yicongsrfy@163.com>
Date: Mon, 22 Sep 2025 09:56:51 +0800
From: yicongsrfy@....com
To: andrew@...n.ch
Cc: Frank.Sae@...or-comm.com,
	davem@...emloft.net,
	edumazet@...gle.com,
	hkallweit1@...il.com,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	linux@...linux.org.uk,
	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 Fri, 19 Sep 2025 14:45:12 +0200, Andrew Lunn <andrew@...n.ch> wrote:
>
> > Since this issue cannot be fundamentally resolved within phylib,
> > we need to seek a solution within the PHY driver itself.
>
> How about this...
>
> Allow a node in DT which looks like this:
>
> mdio {
> 	phy@0 {
> 		# Broadcast address, ignore
> 		compatible = "ethernet-phy-idffff.ffff";
> 		reg = <0>;
> 	}
>
> 	phy@16 {
> 		# The real address of the PHY
> 		reg = <16>;
> 	}
> }
>
> The idea being, you can use a compatible to correct the ID of a PHY.
> The ID of mostly F is considered to mean there is no PHY there, its
> just the pull-up resistor on the data line. So the PHY is returning
> the wrong ID...
>
> of_mdiobus_child_is_phy() then needs to change from a bool to an int,
> and return -ENODEV for "ethernet-phy-idffff.ffff", and the caller
> needs to correctly handle that and not create the device.
>
> I would also suggest the PHY driver disables the broadcast address
> when it gets probed on its real address.

Thank you for your reply!

Disabling the broadcast address from ACPI or DTS is indeed a good
approach. However, should we also consider upgrade support for
existing devices? After all, modifying ACPI or DTS for already-deployed
devices is not a simple task. In cases like this, do we need to focus
solely on solutions implemented within the driver?