mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: James Hilliard <james.hilliard1@gmail.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
	wens@csie.org, netdev@vger.kernel.org,
	linux-sunxi@lists.linux.dev, Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Furong Xu <0x1207@gmail.com>,
	Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] net: stmmac: allow drivers to explicitly select PHY device
Date: Thu, 29 May 2025 01:47:07 +0200	[thread overview]
Message-ID: <0c7a1602-61d3-4840-83f2-72a74ffd52b8@lunn.ch> (raw)
In-Reply-To: <CADvTj4qab272xTpZGRoPnCstufK_3e9CY99Og+2mey2co6u5dg@mail.gmail.com>

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

  reply	other threads:[~2025-05-28 23:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-27 17:55 James Hilliard
2025-05-27 17:55 ` [PATCH v2 2/3] net: stmmac: dwmac-sun8i: Allow runtime AC200/AC300 phy selection James Hilliard
2025-05-27 17:55 ` [PATCH v2 3/3] dt-bindings: net: sun8i-emac: Add AC300 EMAC1 nvmem " James Hilliard
2025-05-27 19:14 ` [PATCH v2 1/3] net: stmmac: allow drivers to explicitly select PHY device Andrew Lunn
2025-05-27 19:21   ` James Hilliard
2025-05-27 20:01     ` Andrew Lunn
2025-05-27 20:16       ` James Hilliard
2025-05-27 20:30         ` Andrew Lunn
2025-05-27 20:37           ` James Hilliard
2025-05-27 21:48             ` Andrew Lunn
2025-05-27 22:47               ` James Hilliard
2025-05-28  7:53             ` Russell King (Oracle)
2025-05-28 11:57               ` James Hilliard
2025-05-28 13:24                 ` Andrew Lunn
2025-05-28 14:11                   ` Chen-Yu Tsai
2025-05-28 17:25                     ` James Hilliard
2025-05-28 18:34                       ` Russell King (Oracle)
2025-05-28 19:10                         ` James Hilliard
2025-05-28 19:26                           ` Andrew Lunn
2025-05-28 19:45                             ` James Hilliard
2025-05-28 21:05                               ` Andrew Lunn
2025-05-28 21:14                                 ` James Hilliard
2025-05-28 21:29                                   ` Andrew Lunn
2025-05-28 21:45                                     ` James Hilliard
2025-05-28 23:47                                       ` Andrew Lunn [this message]
2025-05-29  0:31                                         ` James Hilliard
2025-05-30 23:46       ` James Hilliard
2025-05-30 23:56         ` Florian Fainelli
2025-05-31  0:02           ` James Hilliard
2025-05-31  0:24             ` Florian Fainelli
2025-05-31  0:49               ` James Hilliard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0c7a1602-61d3-4840-83f2-72a74ffd52b8@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=0x1207@gmail.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hayashi.kunihiko@socionext.com \
    --cc=james.hilliard1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=linux@armlinux.org.uk \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®