netdev - Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI with lanes

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]

Date:   Thu, 26 Nov 2020 22:07:48 +0100
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Danielle Ratson <danieller@...dia.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, Andrew Lunn <andrew@...n.ch>,
        Jakub Kicinski <kuba@...nel.org>,
        Ido Schimmel <idosch@...sch.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Jiri Pirko <jiri@...dia.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        mlxsw <mlxsw@...dia.com>, Ido Schimmel <idosch@...dia.com>,
        "johannes@...solutions.net" <johannes@...solutions.net>
Subject: Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI
 with lanes

On Wed, Nov 25, 2020 at 10:35:35AM +0000, Danielle Ratson wrote:
> > > What do you think of passing the link modes you have suggested as a
> > > bitmask, similar to "supported", that contains only one positive bit?
> > > Something like that:
> 
> Hi Michal,
> 
> Thanks for your response.
> 
> Actually what I said is not very accurate. 
> In ethtool, for speed 100G and 4 lanes for example, there are few link modes that fits:
> ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT
> ETHTOOL_LINK_MODE_100000baseSR4_Full_BIT
> ETHTOOL_LINK_MODE_100000baseCR4_Full_BIT
> ETHTOOL_LINK_MODE_100000baseLR4_ER4_Full_BIT
> 
> The difference is the media. And in the driver we shrink into one bit.
> But maybe that makes passing a bitmask more sense, or am I missing something?

But as far as I understand, at any moment, only one of these will be
actually in use so that's what the driver should report. Or is the
problem that the driver cannot identify the media in use? (To be
precise: by "cannot identify" I mean "it's not possible for the driver
to find out", not "current code does not distinguish".)

Michal