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: <CADvTj4r1VvjiK4tj3tiHYVJtLDWtMSJ3GFQgYyteTnLGsQQ2Eg@mail.gmail.com>
Date: Wed, 28 May 2025 15:14:16 -0600
From: James Hilliard <james.hilliard1@...il.com>
To: Andrew Lunn <andrew@...n.ch>
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 3:05 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> 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.

But the boards randomly contain SoC's with different PHY's so we
have to support both variants.

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

Yes, the boards I'm working for example, but this is likely an issue for
other boards as well(vendor BSP auto detects PHY variants):
https://www.zeusbtc.com/ASIC-Miner-Repair/Parts-Tools-Details.asp?ID=1139