netdev - Re: [PATCH net-next v5 1/5] ethtool: introduce core UAPI and driver API for PHY MSE diagnostics

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: <20250912165442.2e3bc13e@kernel.org>
Date: Fri, 12 Sep 2025 16:54:42 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon
 Horman <horms@...nel.org>, Donald Hunter <donald.hunter@...il.com>,
 Jonathan Corbet <corbet@....net>, Heiner Kallweit <hkallweit1@...il.com>,
 Russell King <linux@...linux.org.uk>, Kory Maincent
 <kory.maincent@...tlin.com>, Maxime Chevallier
 <maxime.chevallier@...tlin.com>, Nishanth Menon <nm@...com>,
 kernel@...gutronix.de, linux-kernel@...r.kernel.org,
 netdev@...r.kernel.org, UNGLinuxDriver@...rochip.com,
 linux-doc@...r.kernel.org, Michal Kubecek <mkubecek@...e.cz>, Roan van Dijk
 <roan@...tonic.nl>
Subject: Re: [PATCH net-next v5 1/5] ethtool: introduce core UAPI and driver
 API for PHY MSE diagnostics

On Fri, 12 Sep 2025 12:21:11 +0200 Oleksij Rempel wrote:
> > > All investigated devices differ in MSE configuration parameters, such
> > > as sample rate, number of analyzed symbols, and scaling factors.
> > > For example, the KSZ9131 uses different scaling for MSE and pMSE.
> > > To make this visible to userspace, scale limits and timing information
> > > are returned via get_mse_config().  
> > 
> > But the parameter set is set by the standard? If not we should annotate
> > which one is and which isn't.  
> 
> Do you mean we should show which parameters are defined by a standard
> (for example Open-Alliance - MSE/pMSE) or which parts of the measurement
> method - like how many samples in what time - are vendor or product
> specific?

Yes. Your call if it really makes sense, but if we have a mix it's good
to mention which ones are safe(r) to depend on in mixed environments.
One way to do this would be to annotate the standard ones with standard
references but doesn't seem like the OA standard lends itself to
concise ways of referring to it (like IEEE standards do).

> And should we only write this in comments/docs, or add a flag/enum so
> user space can detect it?

Just comments/docs