linux-kernel - Re: [PATCH net-next 4/5] net: phy: realtek: demystify PHYSR register location

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWFiyMJTYcCBnoWJ@makrotopia.org>
Date: Fri, 9 Jan 2026 20:19:20 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Michael Klein <michael@...sekall.de>,
	Aleksander Jan Bajkowski <olek2@...pl>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 4/5] net: phy: realtek: demystify PHYSR register
 location

On Fri, Jan 09, 2026 at 05:31:40PM +0000, Daniel Golle wrote:
> On Fri, Jan 09, 2026 at 12:26:42PM +0000, Daniel Golle wrote:
> > On Fri, Jan 09, 2026 at 08:32:33AM +0100, Heiner Kallweit wrote:
> > > On 1/9/2026 4:03 AM, Daniel Golle wrote:
> > > > Turns out that register address RTL_VND2_PHYSR (0xa434) maps to
> > > > Clause-22 register MII_RESV2. Use that to get rid of yet another magic
> > > > number, and rename access macros accordingly.
> > > > 
> > > 
> > > RTL_VND2_PHYSR is documented in the datasheet, at least for RTL8221B(I)-VB-CG.
> > > (this datasheet is publicly available, I don't have access to other datasheets)
> > > MII_RESV2 isn't documented there. Is MII_RESV2 documented in any other datasheet?
> > 
> > No datasheet mentions the nature of paging only affecting registers
> > 0x10~0x17, I've figured that out by code analysis and testing (ie.
> > dumping all registers for all known/used pages using mdio-tools in
> > userspace, and writing to PHYCR1 toggling BIT(13) and confirming that it
> > affects the PHY in the expected way). Don't ask me why they ommit this
> > in the datasheets, I suspect the people writing the datasheets are given
> > some auto-generated code and also don't have unterstanding of the actual
> > internals (maybe to "protect" their precious IP?).
> > 
> > Anyway, as RTL_VND2_PHYSR is 0xa434 on MDIO_MMD_VEND2, and we know that
> > 0xa400~0xa43c maps to the standard C22 registers, I concluded that
> > 0xa434 on MDIO_MMD_VEND2 is identical to C22 register 0x1a, ie.
> > MII_RESV2. I've also noticed that the mechanism to translate registers
> > on MDIO_MMD_VEND2 to paged C22 registers only makes use of registers
> > 0x10~0x17, so it became apparent that other registers are not affected
> > by paging.
> > 
> > I've confirmed all that by testing on RTL8211F and RTL8221B. As pointed
> > out this also holds true for internal PHYs on r8169 which emulate C22
> > registers in the exact same way. Hence the PHY driver can be simplified,
> > as there is no need to set and restore the page around the reading of
> > PHYSR.
> 
> Just did some additional testing also with r8169 (with internal 2.5G PHY
> 0x001cc840), and PHYSR reads fine as MII_RESV2, letting the Ethernet
> driver handle the mapping to MDIO_MMD_VEND2 instead of using a paged
> read in the PHY driver.
> 

Same for 10ec:8168
("Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)")
with PHY ID 0x001cc800 ("Generic FE-GE Realtek PHY"), works all fine
with this series applied.

So I agree that for r8169 this change doesn't make a difference, but
for standalone PHYs it does make things more simple and also means
less MDIO operations (1 instead of 3) to do the same thing.