> -----Original Message----- > From: Edwin Peer <[email protected]> > Sent: Monday, January 25, 2021 8:04 PM > To: Danielle Ratson <[email protected]> > Cc: netdev <[email protected]>; David S . Miller <[email protected]>; > Jakub Kicinski <[email protected]>; Jiri Pirko > <[email protected]>; Andrew Lunn <[email protected]>; [email protected]; Michal > Kubecek <[email protected]>; mlxsw > <[email protected]>; Ido Schimmel <[email protected]> > 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 <[email protected]> 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
