-----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
[off-list 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:
quoted
quoted
quoted
+ * @mode_valid: Indicates the validity of the @mode field. Should be set
by
quoted
quoted
quoted
+ * 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