netdev - Re: [net,PATCH] net: phy: dp83869: fix STRAP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <168f8017-8da8-4ec0-878f-dae5b52d1994@mailbox.org>
Date: Sat, 25 Oct 2025 05:09:17 +0200
From: Marek Vasut <marek.vasut@...lbox.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Thanh Quan <thanh.quan.xn@...esas.com>,
 Hai Pham <hai.pham.ud@...esas.com>, "David S. Miller" <davem@...emloft.net>,
 Dan Murphy <dmurphy@...com>, Eric Dumazet <edumazet@...gle.com>,
 Heiner Kallweit <hkallweit1@...il.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Russell King <linux@...linux.org.uk>,
 linux-renesas-soc@...r.kernel.org
Subject: Re: [net,PATCH] net: phy: dp83869: fix STRAP_OPMODE bitmask

On 10/24/25 2:24 AM, Andrew Lunn wrote:

Hello Andrew,

> On Fri, Oct 24, 2025 at 12:39:45AM +0200, Marek Vasut wrote:
>> From: Thanh Quan <thanh.quan.xn@...esas.com>
>>
>> According to the TI DP83869HM datasheet Revision D (June 2025), section
>> 7.6.1.41 STRAP_STS Register, the STRAP_OPMODE bitmask is bit [11:9].
>> Fix this.
> 
> It is a good idea to state in the commit message what the bad
> behaviour is which the patch fixes. Somebody looking through the
> patches can then decide if they need to cherry-pick the patch into
> their dead vendor tree, etc.
> 
> Please add to the commit message what issue you where seeing which
> made you create this patch.

In short, on the hardware I use, the interface to the PHY is SGMII, but 
the driver is confused into thinking it is RGMII based on the STRAP_STS 
register content, and misconfigures the PHY for RGMII.

I plan to extend the commit message this way. I tried to cover all the 
bases there, so people can decide whether the are affected or not. Is 
this understandable or is it maybe too much ?

"
net: phy: dp83869: fix STRAP_OPMODE bitmask

According to the TI DP83869HM datasheet Revision D (June 2025), section
7.6.1.41 STRAP_STS Register, the STRAP_OPMODE bitmask is bit [11:9].
Fix this.

In case the PHY is auto-detected via PHY ID registers, or not described
in DT, or, in case the PHY is described in DT but the optional DT property
"ti,op-mode" is not present, then the driver reads out the PHY functional
mode (RGMII, SGMII, ...) from hardware straps.

Currently, all upstream users of this PHY specify both DT compatible string
"ethernet-phy-id2000.a0f1" and ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>
property, therefore it seems no upstream users are affected by this bug.

The driver currently interprets bits [2:0] of STRAP_STS register as PHY
functional mode. Those bits are controlled by ANEG_DIS, ANEGSEL_0 straps
and an always-zero reserved bit. Systems that use RGMII-to-Copper functional
mode are unlikely to disable auto-negotiation via ANEG_DIS strap, or change
auto-negotiation behavior via ANEGSEL_0 strap. Therefore, even with this bug
in place, the STRAP_STS register content is likely going to be interpreted
by the driver as RGMII-to-Copper mode.

However, for a system with PHY functional mode strapping set to other mode
than RGMII-to-Copper, the driver is likely to misinterpret the strapping
as RGMII-to-Copper and misconfigure the PHY.

For example, on a system with SGMII-to-Copper strapping, the STRAP_STS
register reads as 0x0c20, but the PHY ends up being configured for
incompatible RGMII-to-Copper mode.
"

Thank you for your help !