[PATCH 1/2] arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Cobra
Andrew Lunn
andrew at lunn.ch
Mon Feb 2 06:55:56 PST 2026
On Mon, Feb 02, 2026 at 03:02:08PM +0100, Quentin Schulz wrote:
> Hi Andrew,
>
> On 2/2/26 2:52 PM, Andrew Lunn wrote:
> > On Mon, Feb 02, 2026 at 11:27:25AM +0100, Quentin Schulz wrote:
> > > From: Quentin Schulz <quentin.schulz at cherry.de>
> > >
> > > When not passing the PHY ID with an ethernet-phy-idX.Y compatible
> > > property, the MDIO bus will attempt to auto-detect the PHY by reading
> > > its registers and then probing the appropriate driver. For this to work,
> > > the PHY needs to be in a working state.
> > >
> > > Unfortunately, the net subsystem doesn't control the PHY reset GPIO when
> > > attempting to auto-detect the PHY. This means the PHY needs to be in a
> > > working state when entering the Linux kernel. This historically has been
> > > the case for this device, but only because the bootloader was taking
> > > care of initializing the Ethernet controller even when not using it.
> > > We're attempting to support the removal of the network stack in the
> > > bootloader, which means the Linux kernel will be entered with the PHY
> > > still in reset and now Ethernet doesn't work anymore.
> > >
> > > The devices in the field only ever had a TI DP83825, so let's simply
> > > bypass the auto-detection mechanism entirely by passing the appropriate
> > > PHY IDs via the compatible.
> > >
> > > Cc: stable at vger.kernel.org
> > > Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
> > > Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>
> >
> > What is the justification for stable?
> >
>
> Bootloader without network stack = no network in Linux.
I can see this multiple ways....
Changing the bootloader introduces a regression. Hence you cannot
change the bootloader.
I personally also don't like boot loaders with basic functionality
missing. Why cripple the bootloader by removing the network stack?
But i also don't like Linux being dependent on the bootloader. Because
some vendors ship boards with crippled bootloaders and you need to
replace the bootloader. And then hidden vendor initialization is not
in the mainline version of the bootloader, and something breaks in
Linux. Making Linux more robust is generally ongoing development, not
a bug fix.
However, it bootloader developers decide to break the contract between
the bootloader and the kernel, regressions have been reported, then it
would make sense to backport the fix to work around the bootloader
breakage.
I don't know the internal of uboot too well. Can you remove the IP
stack, but leave the drivers? Get the driver to probe and setup the
PHY, so you keep the agreed contract with Linux, but you also get the
crippled bootloader you want.
For the commit message, i would like to see a reasoned argument, based
on
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
why this should be in stable.
Andrew
More information about the linux-arm-kernel
mailing list