All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Donald Hunter <donald.hunter@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Kory Maincent <kory.maincent@bootlin.com>,
	Maxime Chevallier <maxime.chevallier@bootlin.com>,
	Nishanth Menon <nm@ti.com>,
	kernel@pengutronix.de, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, UNGLinuxDriver@microchip.com,
	linux-doc@vger.kernel.org, Michal Kubecek <mkubecek@suse.cz>,
	Roan van Dijk <roan@protonic.nl>
Subject: Re: [PATCH net-next v2 1/5] ethtool: introduce core UAPI and driver API for PHY MSE diagnostics
Date: Wed, 20 Aug 2025 06:44:22 +0200	[thread overview]
Message-ID: <aKVSpmKR0MGZhAD1@pengutronix.de> (raw)
In-Reply-To: <489b2959-3374-4766-a982-9e7c26077899@lunn.ch>

On Wed, Aug 20, 2025 at 05:03:14AM +0200, Andrew Lunn wrote:
> > Channel-to-pair mapping is normally straightforward, but in some cases
> > (e.g. 100BASE-TX with MDI-X resolution unknown) the mapping is ambiguous.
> > If hardware does not expose MDI-X status, the exact pair cannot be
> > determined. To avoid returning misleading per-channel data in this case,
> > a LINK selector is defined for aggregate MSE measurements.
> 
> This is the same with cable test. The API just labels the pairs using
> 
>         ETHTOOL_A_CABLE_PAIR_A,
>         ETHTOOL_A_CABLE_PAIR_B,
>         ETHTOOL_A_CABLE_PAIR_C,
>         ETHTOOL_A_CABLE_PAIR_D,
> 
> It does not take into account MDI-X or anything.

In the case of the cable test, MDI-X does not affect the reported
results, or if it does, we can actively change the configuration and
re-run the test. For SQI/MSE on this chip, however, the measurement is
purely passive. If the hardware does not expose an MDI-X indicator, we
cannot reliably assign the values to a specific pair, so we need the
LINK selector to avoid returning misleading data.

> > @@ -1174,6 +1246,60 @@ struct phy_driver {
> >  	/** @get_sqi_max: Get the maximum signal quality indication */
> >  	int (*get_sqi_max)(struct phy_device *dev);
> >  
> > +	/**
> > +	 * get_mse_config - Get configuration and scale of MSE measurement
> > +	 * @dev:    PHY device
> > +	 * @config: Output (filled on success)
> > +	 *
> > +	 * Fill @config with the PHY's MSE configuration for the current
> > +	 * link mode: scale limits (max_average_mse, max_peak_mse), update
> > +	 * interval (refresh_rate_ps), sample length (num_symbols) and the
> > +	 * capability bitmask (supported_caps).
> > +	 *
> > +	 * Implementations may defer configuration until hardware has
> > +	 * converged; in that case they should return -EAGAIN and allow the
> > +	 * caller to retry later.
> > +	 *
> > +	 * Return:
> > +	 *  * 0              - success, @config is valid
> > +	 *  * -EOPNOTSUPP    - MSE configuration not implemented by the PHY
> > +	 *		       or not supported in the current link mode
> > +	 *  * -ENETDOWN      - link is down and configuration is not
> > +	 *		       available in that state
> 
> This seems a bit odd. phylib knows the state of the link. If it is
> down, why would it even ask? 

Good point. I'll remove this part of comment.

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2025-08-20  4:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-15  6:35 [PATCH net-next v2 0/5] ethtool: introduce PHY MSE diagnostics UAPI and drivers Oleksij Rempel
2025-08-15  6:35 ` [PATCH net-next v2 1/5] ethtool: introduce core UAPI and driver API for PHY MSE diagnostics Oleksij Rempel
2025-08-20  3:03   ` Andrew Lunn
2025-08-20  4:44     ` Oleksij Rempel [this message]
2025-08-15  6:35 ` [PATCH net-next v2 2/5] ethtool: netlink: add ETHTOOL_MSG_MSE_GET and wire up PHY MSE access Oleksij Rempel
2025-08-15  6:35 ` [PATCH net-next v2 3/5] ethtool: netlink: add lightweight MSE reporting to LINKSTATE_GET Oleksij Rempel
2025-08-19  2:35   ` Jakub Kicinski
2025-08-15  6:35 ` [PATCH net-next v2 4/5] net: phy: micrel: add MSE interface support for KSZ9477 family Oleksij Rempel
2025-08-15  6:35 ` [PATCH net-next v2 5/5] net: phy: dp83td510: add MSE interface support for 10BASE-T1L Oleksij Rempel
2025-08-18  8:15   ` Maxime Chevallier
2025-08-18  9:20     ` Oleksij Rempel
2025-08-20 12:11       ` Andrew Lunn
2025-08-20 12:26         ` Oleksij Rempel
2025-08-20 13:32           ` Andrew Lunn

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=aKVSpmKR0MGZhAD1@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=pabeni@redhat.com \
    --cc=roan@protonic.nl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.