linux-kernel - Re: [PATCH v2 1/3] net: stmmac: allow drivers to explicitly select PHY device

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1e6e4a44-9d2b-4af4-8635-150ccc410c22@lunn.ch>
Date: Wed, 28 May 2025 23:05:25 +0200
From: Andrew Lunn <andrew@...n.ch>
To: James Hilliard <james.hilliard1@...il.com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, wens@...e.org,
	netdev@...r.kernel.org, linux-sunxi@...ts.linux.dev,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Furong Xu <0x1207@...il.com>,
	Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] net: stmmac: allow drivers to explicitly select
 PHY device

On Wed, May 28, 2025 at 01:45:40PM -0600, James Hilliard wrote:
> On Wed, May 28, 2025 at 1:27 PM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > > I think a lot of ethernet drivers use phy_find_first() for phy scanning
> > > as well so it's not limited to just stmmac AFAIU.
> >
> > You need to differentiate by time. It has become a lot less used in
> > the last decade. DT describes the PHY, so there is no need to hunt
> > around for it. The only real use case now a days is USB dongles, which
> > don't have DT, and maybe PCIe devices without ACPI support.
> 
> I mean, hardware probing features for this sort of use case have been
> getting added outside the network subsystem so I'm not sure what the
> issue with this is as those use cases don't appear to be meaningfully
> different.
> 
> > I suggest you give up pushing this. You have two Maintainers saying no
> > to this, so it is very unlikely you are going to succeed.
> 
> So what should I be doing instead?

Describe the one PHY which actually exists in device tree for the
board, and point to it using phy-handle. No runtime detection, just
correctly describe the hardware.

Do you have examples of boards where the SoC variant changed during
the boards production life?

	Andrew