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

[Edwin Peer <edwin.peer@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On Sun, Jan 24, 2021 at 12:36 AM Danielle Ratson <danieller@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.

> > 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

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4160 bytes --]