[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKOOJTxoi71y=4Z2Dm0fOWkNY2WTZ_FZXHxXdEUnyP8TTr9RLA@mail.gmail.com>
Date: Thu, 4 Mar 2021 14:13:43 -0800
From: Edwin Peer <edwin.peer@...adcom.com>
To: Danielle Ratson <danieller@...dia.com>
Cc: netdev <netdev@...r.kernel.org>,
"David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, eric.dumazet@...il.com,
Andrew Lunn <andrew@...n.ch>,
Michal Kubecek <mkubecek@...e.cz>, f.fainelli@...il.com,
acardace@...hat.com, irusskikh@...vell.com, gustavo@...eddedor.com,
magnus.karlsson@...el.com, ecree@...arflare.com,
Ido Schimmel <idosch@...dia.com>, Jiri Pirko <jiri@...dia.com>,
mlxsw <mlxsw@...dia.com>
Subject: Re: [PATCH net] ethtool: Add indicator field for link_mode validity
to link_ksettings
On Thu, Mar 4, 2021 at 2:08 PM Edwin Peer <edwin.peer@...adcom.com> wrote:
> On Thu, Mar 4, 2021 at 1:13 AM Danielle Ratson <danieller@...dia.com> wrote:
>
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -130,6 +130,7 @@ struct ethtool_link_ksettings {
> > } link_modes;
> > u32 lanes;
> > enum ethtool_link_mode_bit_indices link_mode;
> > + bool link_mode_valid;
> > };
>
> Why isn't this handled the same way as is done for lanes, with a
> cap_link_mode_supported bit in ethtool_ops? This would be more
> consistent from a driver API perspective. Then,
> linkmodes_prepare_data() can set link_mode to -1 for drivers that
> don't claim to supply link_mode.
Or rather, since that happens too late, don't set it -1 at all and
only set the implied parameters in __ethtool_get_link_ksettings()
according to the capability.
Regards,
Edwin Peer
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4203 bytes)
Powered by blists - more mailing lists