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

On Tue, Aug 24, 2021 at 11:18:56PM +0000, Keller, Jacob E wrote:

quoted

-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: Tuesday, August 24, 2021 4:13 PM
To: Ido Schimmel <redacted>
Cc: netdev@vger.kernel.org; davem@davemloft.net; andrew@lunn.ch;
mkubecek@suse.cz; pali@kernel.org; Keller, Jacob E [off-list ref];
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 16:03:39 +0300 Ido Schimmel wrote:

[...]

quoted

quoted

+/**
+ * struct ethtool_module_power_mode_params - module power mode

parameters

quoted

+ * @policy: The power mode policy enforced by the host for the plug-in

module.

quoted

+ * @mode: The operational power mode of the plug-in module. Should be

filled by

quoted

+ * device drivers on get operations.

Indent continuation lines by one tab.

quoted

+ * @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 different, IIUC. In coalesce settings, the driver declares which
parameters are allowed in "set" requests so that this part of request
checks can be done in the general ethtool code rather than in each
driver separately. Here the "valid" field says whether mode field holds
a meaningful value or should be ignored.

Michal