[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKOOJTw2Z_SdPNsDeTanSatBLZ7=vh2FGjn_NASVUK2hbK7Q3Q@mail.gmail.com>
Date: Mon, 1 Feb 2021 10:14:35 -0800
From: Edwin Peer <edwin.peer@...adcom.com>
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" <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 Mon, Feb 1, 2021 at 5:49 AM Danielle Ratson <danieller@...dia.com> wrote:
> 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?
I think it should be deterministic. It should be possible to select
the appropriate mode either based on the current media type or the
current link mode (which implies a media type). Alternatively, if the
user space request only specifies a subset, such as speed, fall back
to the existing behaviour and don't supply the request to the driver
in the form of a compound link mode in those cases (perhaps indicating
this by not setting the capability bit). The former approach has the
potential to tidy up drivers if we decide that drivers providing the
capability can ignore the other fields and rely solely on link mode,
the latter is no worse than what we have today.
Regards,
Edwin Peer
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4160 bytes)
Powered by blists - more mailing lists