[PATCH 1/2] arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Cobra

[Quentin Schulz]

On 2/2/26 3:55 PM, Andrew Lunn wrote:
> 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.
> 

Ringneck is a SoM (system-on-module), I don't control what the user 
wants to do with it. So they may never have the networking stack enabled 
in the first place (I provide a U-Boot defconfig to use with the devkit, 
but I don't control what they do with it; it's also supported upstream 
so if they want to use that, they can).

> I personally also don't like boot loaders with basic functionality
> missing. Why cripple the bootloader by removing the network stack?
> 

The answer is pretty simple here, no network stack, no bug to exploit 
there, smaller binary, faster boot. On finished products with secure 
boot, a crippled bootloader is fine (and desired). It does what it's 
supposed to do, nothing else. I also don't control what our clients will 
do with our SoM in their product (and I don't necessarily have feedback 
either).

> But i also don't like Linux being dependent on the bootloader. Because

That's my main concern and only reason for marking this a stable 
candidate. We shouldn't have to rely on the bootloader doing something.

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

This issue is not related to an API between the bootloader and kernel, 
so there's no explicit contract.

> 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

There would be no reason for U-Boot to support having networking drivers 
compiled in when there's no network stack so I would even go as far as 
saying if that's the case, it's a bug. If I were to enable a MAC 
controller and Ethernet PHY drivers with menuconfig, I'd expect them to 
be working in U-Boot.

In any case, I'm not interested in doing that if that even is possible. 
Audit companies and certification authorities may look into what's 
compiled in and ask questions about those drivers or stacks. Not 
compiled in, don't need to argue about them (I have had to do this for 
every CVE in the kernel in the past, so it's not a theoretical).

> PHY, so you keep the agreed contract with Linux, but you also get the
> crippled bootloader you want.
> 

If I wanted to go this route, I can simply toggle the PHY reset GPIO in 
U-Boot and be done with it. I still cannot control whether our Ringneck 
users had the network stack enabled in their bootloader and cannot force 
them to patch it to either add the network stack or this PHY reset 
toggling. I want a clean solution if I can have one.

Cobra support was upstreamed with this issue, so I could see this as not 
being a candidate for stable but an improvement according to the 
standard you stated.

Ringneck on the other hand used to work without a network stack in 
U-Boot before 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e463625af7f92c4a9f097f7fb87f6baaad6e762a, 
so I think this is a regression (I don't control the bootloader of the 
final user, only the default one on our devkit but even then, I don't 
control what they flash on their setups).

Also just to be clear, Theobroma (theobroma-systems.com domain name for 
mails, "tsd," prefix in compatibles) was acquired by CHERRY (cherry.de 
domain name for mails) in 2021, we're the manufacturer, vendor and 
developer of the boards in this patch series. (Not sure if it helps, but 
I can imagine some confusion with my mail address and the original name 
of the device manufacturer).

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

Since you haven't answered on patch 2, I'm assuming that

"""
Note that this is only an issue since commit e463625af7f9 ("arm64: dts:
rockchip: move reset to dedicated eth-phy node on ringneck") as before
that commit the reset was done by the MAC controller before starting the
MDIO auto-detection mechanism, via the snps,reset-* properties.
"""

is a reasoned argument for making that patch a stable candidate.

I don't care too much about stable releases for Cobra as no third party 
is or will be involved in BSP development so I know for sure which 
version we're using and that it is appropriately patched (until we 
migrate to a newer kernel with this patch merged). Also, we're the only 
one able to change anything on that device due to secure boot so no need 
to care about hypothetical flashing. So Heiko, if you agree with Andrew 
here you can either drop the trailer when applying this patch or I can 
send a v2 dropping the Cc: stable trailer for the Cobra patch.

For what it's worth, I agree with what you've said Andrew. I sympathize 
with the dilemma.

Quentin