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: <c14b1dae-142e-4038-92a9-cfcad492f4e2@bootlin.com>
Date: Thu, 27 Nov 2025 16:31:50 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>, Oleksij Rempel <o.rempel@...gutronix.de>
Cc: 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

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.

I think we can no longer really say "If your driver is simple enough,
you can stick to using phylib directly", at least not for new drivers,
as phylink now simplifies EEE, WoL, Pause, etc.

> 2) For those who don't use phylink give clear documentation of the
>    basics.
> 
> We can look at edge cases, but i would only do it in the context of
> phylink. Its one central implementation means we can add complexity
> there and not overload developers who get the basics wrong.
> 
> 	Andrew

Maxime