linux-kernel - Re: [PATCH net-next v8 1/1] Documentation: net: add flow control guide and document ethtool API

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: <b4ae88a8-3db7-434a-92d8-90734f6d7682@lunn.ch>
Date: Thu, 27 Nov 2025 16:48:42 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>,
	Jakub Kicinski <kuba@...nel.org>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Alexei Starovoitov <ast@...nel.org>,
	Russell King <linux@...linux.org.uk>,
	Eric Dumazet <edumazet@...gle.com>, Rob Herring <robh@...nel.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Donald Hunter <donald.hunter@...il.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	Jonathan Corbet <corbet@....net>,
	John Fastabend <john.fastabend@...il.com>,
	Lukasz Majewski <lukma@...x.de>,
	Stanislav Fomichev <sdf@...ichev.me>,
	Paolo Abeni <pabeni@...hat.com>, Jiri Pirko <jiri@...nulli.us>,
	Jesper Dangaard Brouer <hawk@...nel.org>,
	Divya.Koppera@...rochip.com,
	Kory Maincent <kory.maincent@...tlin.com>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>, netdev@...r.kernel.org,
	Sabrina Dubroca <sd@...asysnail.net>, linux-kernel@...r.kernel.org,
	kernel@...gutronix.de, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH net-next v8 1/1] Documentation: net: add flow control
 guide and document ethtool API

On Thu, Nov 27, 2025 at 04:31:50PM +0100, Maxime Chevallier wrote:
> Hi Andrew
> 
> I am sorry, I have a bit of sidetracking...
> 
> >> State Persistence and Toggling When toggling autoneg (e.g., autoneg on -> off
> >> -> on), should the kernel or driver cache the previous advertisement?
> > 
> > This has been discussed in the past, and i _think_ phylink does.
> > 
> > But before we go too far into edge causes, my review experience is
> > that MAC drivers get the basics wrong. What we really want to do here
> > is:
> > 
> > 1) Push driver developers towards phylink
> 
> Is it something we should insist on in the review process ? Can we make
> it a hard requirement that _new_ MAC drivers need to use phylink, if the
> driver plans to interact with a PHY ?
> 
> phylink has long outgrown the original use-case of supporting SFPs by
> abstracting away the MAc to [PHY/SFP] interactions, it's now used as a
> an abstraction layer that avoids MAC drivers making the same mistakes
> over and over again on a lot of cases that don't have anything to do
> with SFP.

This is something i've been considering for a while.

Maybe for the last year, when i have seen broken pause, i've been
reporting the problems but also pushing developers towards
phylink. phylink also does all the business logic for EEE, and is
starting to get WoL support. So we really should be pushing developers
in that direction.

Is it time to deprecated direct phylib access?

I think the answer is Yes.

	Andrew