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:

quoted

On Mon, Feb 02, 2026 at 11:27:25AM +0100, Quentin Schulz wrote:

quoted

From: Quentin Schulz <redacted>

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@vger.kernel.org
Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
Signed-off-by: Quentin Schulz <redacted>

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