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: <aWE7fPY64ew-MY6Q@makrotopia.org>
Date: Fri, 9 Jan 2026 17:31:40 +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 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ