Message-ID: <0c7a1602-61d3-4840-83f2-72a74ffd52b8@lunn.ch>
Date: Thu, 29 May 2025 01:47:07 +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

> > 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.

> > > > 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 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.

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? 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? 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.

	Andrew

Powered by blists - more mailing lists