# RE: \[RFC PATCH net-next v3 1/6\] ethtool: Add ability to control transceiver modules' power mode

- From: Keller, Jacob E \<jacob.e.keller@intel.com\>
- Date: 2021-08-25 07:35:14 
- List: netdev
- Page: https://ratatoskr.run/netdev/2021/08/11210095
- Thread: https://ratatoskr.run/netdev/2021/08/11210023/t.md

```text


> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Tuesday, August 24, 2021 4:48 PM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: Ido Schimmel <redacted>; <redacted>;
> davem@davemloft.net; andrew@lunn.ch; mkubecek@suse.cz; pali@kernel.org;
> jiri@nvidia.com; vadimp@nvidia.com; mlxsw@nvidia.com; Ido Schimmel
> [ref]
> Subject: Re: [RFC PATCH net-next v3 1/6] ethtool: Add ability to control
> transceiver modules' power mode
> 
> On Tue, 24 Aug 2021 23:18:56 +0000 Keller, Jacob E wrote:
> > > > + * @mode_valid: Indicates the validity of the @mode field. Should be set
> by
> > > > + * device drivers on get operations when a module is plugged-in.
> > >
> > > Should we make a firm decision on whether we want to use these kind of
> > > valid bits or choose invalid defaults? As you may guess my preference
> > > is the latter since that's what I usually do, that way drivers don't
> > > have to write two fields.
> > >
> > > Actually I think this may be the first "valid" in ethtool, I thought we
> > > already had one but I don't see it now..
> >
> > coalesce settings have a valid mode don't they? Or at least an "accepted
> modes"?
> 
> That's a static per-driver bitmask 'cause we don't trust driver writers
> to error out on all the unsupported fields. The driver code doesn't
> operate on it in the callbacks.

Ahh. Right. Ok yea this is different here.

If we can keep it simple in the drivers, great! I usually like the valid approach, but mostly if its kernel-core code doing it since we're more likely to catch and review that as opposed to individual drivers.

If we're expecting drivers to set validity, a simpler interface would be preferable.

Thanks,
Jake
```