Linux Documentation
 help / color / mirror / Atom feed
From: "Maxime Chevallier (Netdev Foundation)" <maxime.chevallier@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>, Jakub Kicinski <kuba@kernel.org>,
	davem@davemloft.net, Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>
Cc: "Maxime Chevallier (Netdev Foundation)"
	<maxime.chevallier@bootlin.com>,
	Oleksij Rempel <o.rempel@pengutronix.de>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	thomas.petazzoni@bootlin.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: [PATCH net-next v3 0/3] selftests: drv-net: Introduce flow-control selftest
Date: Thu, 15 Oct 2026 15:43:45 +0200	[thread overview]
Message-ID: <20261015134350.629593-1-maxime.chevallier@bootlin.com> (raw)

Hi everyone,

This is V3 for the ethtool flow control test.

This test aims at validating the flow control implementation in drivers,
using the ethtool API.

The test can run in various conditions :

DUT <-----> Anything that has link up (not controllable)
DUT <-----> A directly connected device

It enumerates the local and remote device's capabilities, to test as
much as possibly testable. I've run it on 17 different boards connected
to other boards through various means : Usb to Eth dongles, direct
connection to the board, connection through a switch. Some of the ports
tested were user ports of DSA switches too.

Contrary to V2, on V3 we really only have a collection of actual
failures that show during tests, as one of the peer's I'm running these
on has a v6.18 kernel that pre-dates the realtek phylink port and show
actual bugs in the driver.

Thanks to the Netdev Foundation for funding this work :)

Maxime

Changes in V3:
 - Use Jakub's loop on carrier state when waiting for the interface to
   be up
 - Following discussions with Andrew, we now detect the link partner
   using ethtool -r to trigger an autoneg, instead of assuming the link
   will drop when the interface is brought down
 - Numerous typo fixes and comment reworks
 - wait_for_link and wait_for_aneg have been reworked
 - We no longer expect that pause advertising is empty when pause
   autoneg is off, as documented in uAPI.

Changes in V2:
V2: https://lore.kernel.org/r/20260925182628.214667-1-maxime.chevallier@bootlin.com
 - Don't add stuff to the lib
 - Fix most pylink errors (module's too long for pylint ...)
 - Ditch the fail=False from the defer()
 - Remove duplicate patches
 - Clean the comments
 - Drop the return type annotations, most were wrong...

V1 : https://lore.kernel.org/netdev/20260920164732.349744-1-maxime.chevallier@bootlin.com/

Maxime Chevallier (Netdev Foundation) (3):
  selftests: drv-net: Introduce a selftest for ethtool flow control
  selftests: drv-net: pause: Validate the pause autonegotiation with a
    partner
  selftests: drv-net: pause: Validate pause autoneg interactions with
    link autoneg

 .../testing/selftests/drivers/net/hw/Makefile |   1 +
 .../testing/selftests/drivers/net/hw/pause.py | 944 ++++++++++++++++++
 2 files changed, 945 insertions(+)
 create mode 100755 tools/testing/selftests/drivers/net/hw/pause.py

-- 
2.55.0


             reply	other threads:[~2026-10-15 13:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 13:43 Maxime Chevallier (Netdev Foundation) [this message]
2026-10-15 13:43 ` [PATCH net-next v3 1/3] selftests: drv-net: Introduce a selftest for ethtool flow control Maxime Chevallier (Netdev Foundation)
2026-10-15 13:43 ` [PATCH net-next v3 2/3] selftests: drv-net: pause: Validate the pause autonegotiation with a partner Maxime Chevallier (Netdev Foundation)
2026-10-15 13:43 ` [PATCH net-next v3 3/3] selftests: drv-net: pause: Validate pause autoneg interactions with link autoneg Maxime Chevallier (Netdev Foundation)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261015134350.629593-1-maxime.chevallier@bootlin.com \
    --to=maxime.chevallier@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=skhan@linuxfoundation.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox