netdev - Re: Ethtool: advance phy debug support

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: <62469297-d873-46cb-9c44-0467fd49b732@bootlin.com>
Date: Fri, 14 Nov 2025 17:18:49 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>, Lee Trager <lee@...ger.us>
Cc: Susheela Doddagoudar <susheelavin@...il.com>, netdev@...r.kernel.org,
 mkubecek@...e.cz, Hariprasad Kelam <hkelam@...vell.com>,
 Alexander Duyck <alexanderduyck@...com>
Subject: Re: Ethtool: advance phy debug support

> Linux's understanding of a PHY is a device which takes the bitstream
> from the MAC and turns it into analogue signals on twisted pairs,
> mostly for an RJ45 connector, but automotive uses other
> connectors. Its copper, and 802.3 C22 and parts of C45 define how such
> a PHY should work. There is a second use case, where a PHY converts
> between say RGMII and SGMII, but it basically uses the same registers.
> 
> fbnic is not copper. It has an SFP cage. Linux has a different
> architecture for that, MAC, PCS and SFP driver. Alex abused the design
> and put a PHY into it as a shortcut. It not surprising there was push
> back.
> 
> So, i still think ethtool is the correct API. In general, that
> connects to the MAC driver, although it can shortcut to a PHY
> connected to a MAC. But such a short cut has caused issues in the
> past. So i would probably not do that. Add an API to phylink, which
> the MAC can use. And an API to the PCS driver, which phylink can
> use. And for when the PHY implements PRBS, add an API to phylib and
> get phylib to call the PHY driver.

I also think ethtool is the right spot. In the above explanation, there
may be one more bridge to make between the net world (i.e. the MAC
driver) and the Generic PHY subsystem (drivers/phy). The Comphy driver
for Marvell devices for example is implemented there, for the really low
level, Serdes configuration operations.

If PRBS is implemented there, we may end-up in a situation where ethtool
asks the netdev for PRBS (either directly, or through phylink), which
will in turn ask the generic phy framework for that.

Maxime