From: Quentin Schulz <quentin.schulz@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@vger.kernel.org
Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
arch/arm64/boot/dts/rockchip/px30-cobra.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi b/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
index b7e669d8ba4d1..add917af5de78 100644
--- a/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
@@ -397,7 +397,7 @@ &io_domains {
&mdio {
dp83825: ethernet-phy@0 {
- compatible = "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id2000.a140";
reg = <0x0>;
pinctrl-names = "default";
pinctrl-0 = <&phy_rst>;
--
2.52.0On Mon, Feb 02, 2026 at 11:27:25AM +0100, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@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@vger.kernel.org
> Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
What is the justification for stable?
Andrew
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@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@vger.kernel.org
>> Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>
> What is the justification for stable?
>
Bootloader without network stack = no network in Linux.
Cheers,
Quentin
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@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@vger.kernel.org
> > > Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
> > > Signed-off-by: Quentin Schulz <quentin.schulz@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
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@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@vger.kernel.org
>>>> Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
>>>> Signed-off-by: Quentin Schulz <quentin.schulz@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
© 2016 - 2026 Red Hat, Inc.