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: <aSh411Hogj3O4VT5@shell.armlinux.org.uk>
Date: Thu, 27 Nov 2025 16:14:15 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>,
	Jakub Kicinski <kuba@...nel.org>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Alexei Starovoitov <ast@...nel.org>,
	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>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	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:07:19PM +0100, Andrew Lunn wrote:
> There is one additional thing which plays into this, link
> autonegotiation, ethtool -s autoneg on|off.
> 
> If link auto negotiation is on, you can then have both of the two
> cases above, negotiated pause, or forced pause. If link auto
> negotiation is off, you can only have forced mode. The text you have
> below does however cover this. But this is one of the areas developers
> get wrong, they don't consider how the link autoneg affects the pause
> autoneg.

If there is no autoneg exchange, the capabilities of the remote end have
to be assumed to be Pause=0 AsymDir=0.

> But i do agree that get_pauseparam is rather odd. It returns the
> current configuration, not necessarily how the MAC hardware has been
> programmed.
> 
> > **Common Constraints**
> > Regardless of the mode, the following constraints apply:
> > 
> > - Link-wide PAUSE is not valid on half-duplex links.
> > - Link-wide PAUSE cannot be used together with Priority-based Flow Control
> >   (PFC).
> > 
> > 
> > /**
> >  * ...
> >  * @get_pauseparam: Report the configured administrative policy for link-wide
> >  *	PAUSE (IEEE 802.3 Annex 31B). Drivers must fill struct ethtool_pauseparam
> >  *	such that:
> >  *	@autoneg:
> >  *		This refers to **Pause Autoneg** (IEEE 802.3 Annex 31B) only
> >  *		and is part of the link autonegotiation process.
> >  *		true  -> the device follows the negotiated result of pause
> >  *			 autonegotiation (Pause/Asym);
> >  *		false -> the device uses a forced configuration independent
> >  *			 of negotiation.
> >  *	@rx_pause/@...pause:
> >  *		represent the desired policy (administrative state).
> >  *		In autoneg mode they describe what is to be advertised;
> >  *		in forced mode they describe the MAC configuration to be forced.
> >  *
> >  * @set_pauseparam: Apply a policy for link-wide PAUSE (IEEE 802.3 Annex 31B).
> >  *	@rx_pause/@...pause:
> >  *		Desired state. If @autoneg is true, these define the
> >  *		advertisement. If @autoneg is false, these define the
> >  *		forced MAC configuration.
> >  *	@autoneg:
> >  *		Select autonegotiation or forced mode.
> >  *
> >  *	**Constraint Checking:**
> >  *	Drivers should reject a non-zero setting of @autoneg when
> >  *	autonegotiation is disabled (or not supported) for the link.
> >  *	Drivers should reject unsupported rx/tx combinations with -EINVAL.

Definitely not. Drivers should accept autoneg=1 because that is the
user stating "my desire is to use the result of autonegotiation when
it becomes available". Just because autoneg may be disabled doesn't
mean it will remain disabled, and having to issue ethtool commands
in the right sequence leads to poor user experiences.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!