> -----Original Message----- > From: Edwin Peer <edwin.p...@broadcom.com> > Sent: Monday, January 25, 2021 8:04 PM > To: Danielle Ratson <daniel...@nvidia.com> > Cc: netdev <netdev@vger.kernel.org>; David S . Miller <da...@davemloft.net>; > Jakub Kicinski <k...@kernel.org>; Jiri Pirko > <j...@nvidia.com>; Andrew Lunn <and...@lunn.ch>; f.faine...@gmail.com; Michal > Kubecek <mkube...@suse.cz>; mlxsw > <ml...@nvidia.com>; Ido Schimmel <ido...@nvidia.com> > Subject: Re: [PATCH net-next v3 2/7] ethtool: Get link mode in use instead of > speed and duplex parameters > > On Sun, Jan 24, 2021 at 12:36 AM Danielle Ratson <daniel...@nvidia.com> wrote: > > > > Why isn't this also handled using a capability bit as is done for > > > lanes? Is link_mode read-only? Should it / will it always be? If not, > > > can drivers also derive the other fields if asked to set link_mode? > > > > The link_mode param is only for deriving all the speed, lanes and duplex > > params in ethtool instead of deriving in driver and then > > passing each individual, as Michal asked. > > I understand the benefit of deriving the dependent fields in core code > rather than in each driver, I just don't think this is necessarily > mutually exclusive with being able to force a particular link mode at > the driver API, making link_mode R/W (and even extend this interface > to user space). For a driver that works internally in terms of the > link_mode it's returning, this would be more natural.
I am not sure I fully understood you, but it seems like some expansion that can be done in the future if needed, and doesn't need to hold that patchset back. Thanks, Danielle > > > > That would be easy enough. Why don't we simply allow user space to set > > > link mode directly too (in addition to being able to constrain lanes > > > for autoneg or forced speeds)? > > > > It is already possible to do using 'advertise' parameter. > > That's not the same thing. If it were, you wouldn't need the lanes > parameter in the first place. > > Regards, > Edwin Peer
