linux-kernel - Re: [PATCH v10] net: mdio: Add RTL9300 MDIO driver

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: <Z9Nj2ZRnh8ZABklp@makrotopia.org>
Date: Thu, 13 Mar 2025 23:01:45 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Chris Packham <Chris.Packham@...iedtelesis.co.nz>,
	"hkallweit1@...il.com" <hkallweit1@...il.com>,
	"linux@...linux.org.uk" <linux@...linux.org.uk>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"markus.stockhausen@....de" <markus.stockhausen@....de>,
	"sander@...nheule.net" <sander@...nheule.net>,
	netdev <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v10] net: mdio: Add RTL9300 MDIO driver

On Thu, Mar 13, 2025 at 11:07:55PM +0100, Andrew Lunn wrote:
> > I'm pretty sure it would upset the hardware polling mechanism which 
> > unfortunately we can't disable (earlier I thought we could but there are 
> > various switch features that rely on it).
> 
> So we need to get a better understanding of that polling. How are you
> telling it about the aquantia PHY features? How does it know it needs
> to get the current link rate from MDIO_MMD_AN, MDIO_AN_TX_VEND_STATUS1
> which is a vendor register, not a standard C45 register? How do you
> teach it to decode bits in that register?

There are several registers of the MDIO controller to control which
non-standard registers are polled as well as information about the
register layout [1].

There are lots of constraints which is why not all PHYs can even be
used at all with those switch SoCs -- PHYs which are more or less
standard C45 are easy to support, all one got to do is define MMD
device and registers as well as register layouts for things which
aren't covered by the C45 standard (1G Master/Slave status and control,
as well as a way to access the equivalent of C22 register 0).

But C22 PHYs which aren't RealTek's won't ever work.
Anything which doesn't use register 0x1f for paging is disqualified and
can't be used. I've also just never seen any of those SoCs being used with
anything else than RealTek's 1000Base-T or 2500Base-T PHYs.

Only for 10GBase-T you will find variation, Marvell, Aquantia and some
with Broadcom.

Obviously that's all largely incompatible with Linux' approach to PHY
drivers. Luckily *most* (but not all) switches based on those RealTek
SoC's initialize the PHY polling registers in U-Boot, so usually Linux
doesn't have to touch that (that's why usually we have to make sure
that 'rtk network on' is called in RealTek's U-Boot before launching
Linux).

[1]: There is a very useful reverse-engineered register documentation for
those RealTek SoCs which also covers those registers of the RTL9300:

https://svanheule.net/realtek/longan/feature/mac_control

See SMI_REG_CHK_* and everything with 'POLL' in the register name to get
an idea...

For illustation see the default value of SMI_10GPHY_POLLING_SEL_0 which
is 0x001f_a434. So that's what is called 'RTL_VND2_PHYSR' in the Linux
driver for RealTek PHYs...