[PATCH v2 1/3] net: stmmac: allow drivers to explicitly select PHY device
James Hilliard
james.hilliard1 at gmail.com
Wed May 28 14:14:16 PDT 2025
On Wed, May 28, 2025 at 3:05 PM Andrew Lunn <andrew at lunn.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 at lunn.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
More information about the linux-arm-kernel
mailing list