Message-ID: <CADvTj4q96aGsPi6wfMaxTnC-52-Svu_K6raj=LWyOJd+DniEUQ@mail.gmail.com>
Date: Wed, 28 May 2025 18:31:03 -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 5:47 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > > Or, as Russell suggested, you give the bootloader both .dtb blobs, and
> > > it can pick the correct one to pass to the kernel. Or the bootloader
> > > can patch the .dtb blob to make it fit the hardware.
> >
> > This is what I'm really trying to avoid since it requires special
> > handling in the bootloader and therefore will result in a lot of broken
> > systems since most people doing ports to H616 based boards will only
> > ever test against one PHY variant.
>
> Which in some ways is good. They will then issue four letter words at
> Allwinner, and go find a better SoC vendor.

No, they won't, because the vendor that actually buys from Allwinner
also uses the BSP and doesn't care as long as the BSP works.

>
> > > > > 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
> > >
> > > Mainline generally does not care what vendors do, because they often
> > > do horrible things. Which is O.K, it is open source, they can do what
> > > they want in their fork of the kernel.
> >
> > That's not really true IMO, mainline implements all sorts of workarounds
> > for various vendor hardware quicks/weirdness.
> >
> > > But for Mainline, we expect a high level of quality, and a uniform way
> > > of doing things.
> >
> > Sure, and I'm trying to do that here rather than do some super hacky
> > unmaintainable bootloader based device tree selector.
> >
> > > This can also act as push back on SoC vendors, for doing silly things
> > > like changing the PHY within a SoC without changing its name/number.
> >
> > It won't here, because Allwinner doesn't care about non-BSP kernels.
>
> It can be indirect pressure. There are some OEMs which care about
> Mainline. They will do their due diligence, find that user report
> Mainline if flaky on these devices, and go find a different
> vendor.

There are zero OEMs in my industry that provide hardware with
any mainline support at all. The vendors are outright hostile to 3rd
party firmware and put significant effort into preventing 3rd party
firmware. The OEMs will view the lack of mainline support as a bonus
unfortunately as they like everything locked down.

> There will be some OEM which get burnt by this mess, and when
> they come to their second generation device, they will switch vendor
> and tell the old vendor why. It could well be Allwinner can support
> their bottom line without caring about Mainline, so really don't
> care. But Mainline can help point OEMs away from them to those which
> are more Mainline friendly.

The OEMs in my industry will not change due to a lack of mainline
support, they have no interest in mainline support, they only care
that their products work well enough to sell, and since there is
little competition

> We also need to think about this as a two way street. What does this
> SoC bring to Mainline? Why should Mainline care about it?

The H616 is used in a number of development boards(orangepi and
such) and TV boxes, having decent mainline support at least allows
downstream integrators to have a chance at improving the situation
regardless of vendor cooperation, maybe the SoC vendor will
eventually care if people are actually using mainline kernels more.

> It has some
> major design issues, do we want to say that is O.K? Do we want other
> vendors to think we are O.K. with bad designs?

I mean, it's a second source issue for the PHY, less of an outright
design issue and more likely was just some cost optimization.

If we excluded all vendors with bad designs then Linux would have
far less hardware support.

> Worse still, this is
> stmmac, which lots of vendors already abuse in lots of different
> ways. Russell has put in a lot of effort recently to clean up some of
> that abuse, and we are pushing back hard on new abusers.
>
> If you can hide this mess away in the bootloader, it just looks like a
> regular device, we are likely to accept it. If you try to do something
> different to the normal for PHYs, we are very likely to reject it.

I'm confused, the kernel isn't the bootloader so how can it be accepted
by the kernel if the implementation is not in the kernel? Linux supports
plenty of weird hardware so I really don't see why having a quirk for
this specific board is such a problem as long as the quirk doesn't
introduce maintainability issues.

Powered by blists - more mailing lists