netdev - RE: [PATCH net-next v3 2/7] ethtool: Get link mode in use instead of speed and duplex parameters

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 1 Feb 2021 13:49:43 +0000
From:   Danielle Ratson <danieller@...dia.com>
To:     Edwin Peer <edwin.peer@...adcom.com>
CC:     Michal Kubecek <mkubecek@...e.cz>, netdev <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "Jiri Pirko" <jiri@...dia.com>, Andrew Lunn <andrew@...n.ch>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        mlxsw <mlxsw@...dia.com>, "Ido Schimmel" <idosch@...dia.com>
Subject: RE: [PATCH net-next v3 2/7] ethtool: Get link mode in use instead of
 speed and duplex parameters



> -----Original Message-----
> From: Edwin Peer <edwin.peer@...adcom.com>
> Sent: Sunday, January 31, 2021 7:39 PM
> To: Danielle Ratson <danieller@...dia.com>
> Cc: Michal Kubecek <mkubecek@...e.cz>; netdev <netdev@...r.kernel.org>; David S . Miller <davem@...emloft.net>; Jakub
> Kicinski <kuba@...nel.org>; Jiri Pirko <jiri@...dia.com>; Andrew Lunn <andrew@...n.ch>; f.fainelli@...il.com; mlxsw
> <mlxsw@...dia.com>; Ido Schimmel <idosch@...dia.com>
> Subject: Re: [PATCH net-next v3 2/7] ethtool: Get link mode in use instead of speed and duplex parameters
> 
> On Sun, Jan 31, 2021 at 7:33 AM Danielle Ratson <danieller@...dia.com> wrote:
> 
> > Edwin, adding the a new parameter requires a new patchset in my opinion.
> > Implementing the symmetrical side of the link_mode get, however can be a
> > part of this set. But, the problem with that would be that, as Michal said,
> > speed lanes and duplex can't provide us a single link_mode because of the
> > media. And since link_mode is one bit parameter, passing it to the driver
> > while randomly choosing the media, may cause either information loss, or
> > even fail to sync on a link mode if the chosen media is specifically not
> > supported in the lower levels. So, in my opinion it is related to adding the
> > new parameter we discussed, and should be done in a separate set.
> 
> Media is a little special in the sense that it physically depends on
> what's plugged in. In that sense, media is truly read only. Setting it
> won't change what's plugged in, so not having a separate knob for it
> is probably okay, as it can be inferred from the active link mode on
> the query side.
> 
> I don't see why the driver can't error if asked to set a link mode
> having an incompatible media? The link modes corresponding to media
> that's not plugged in wouldn't be listed in the supported set, so
> there's no reason the user should expect to be able to set those.
> There's no ambiguity or information loss if you refuse to set modes
> that don't have the matching media attached.
> 
> Regards,
> Edwin Peer

Ok, ill send another version with the symmetrical side. Ethtool will try to compose
a supported link_mode from the parameters from user space and will choose
randomly between the supported ones. Sounds ok?

Thanks,
Danielle