[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9703dd41-e1e6-42d8-a43b-01db7b38d11c@lunn.ch>
Date: Wed, 30 Jul 2025 16:15:47 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Gal Pressman <gal@...dia.com>
Cc: Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
Michael Chan <michael.chan@...adcom.com>,
Pavan Chebbi <pavan.chebbi@...adcom.com>,
Tariq Toukan <tariqt@...dia.com>, intel-wired-lan@...ts.osuosl.org,
Donald Hunter <donald.hunter@...il.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] ethtool: add FEC bins histogramm report
> Or just let the driver fill the netlink attributes directly? Not sure if
> we have precedent for that.
A variant on that exists, for cable testing. For BaseT, you can have
1, 2 or 4 pairs. Hence you need 1, 2 or 4 test results. There are
helpers which a driver can use to add test results. You can call them
as many times as you want.
The thing about cable testing is that it is not standardised in any
way, so vendors get to use there imagination. However, there are only
a limited number of ways a cable can be broken, and you can measure
the distance to the break, but not too much more. So i provided a set
of helpers to add well defined nested attributes, and it is up to user
space to handle whatever it receives, which might or might not include
all pairs, might have the length attribute or not, etc.
However, it seems like this is well defined in the standard, so i
don't think you need such flexibility. A single helper is all that
should be needed to add a bin.
So it does exist, but this does go against the general pattern.
Andrew
Powered by blists - more mailing lists