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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211004180135.55759be4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 4 Oct 2021 18:01:35 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, andrew@...n.ch,
        mkubecek@...e.cz, pali@...nel.org, jacob.e.keller@...el.com,
        jiri@...dia.com, vadimp@...dia.com, mlxsw@...dia.com,
        Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next 1/6] ethtool: Add ability to control
 transceiver modules' power mode

On Sun,  3 Oct 2021 10:32:14 +0300 Ido Schimmel wrote:
> From: Ido Schimmel <idosch@...dia.com>
> 
> Add a pair of new ethtool messages, 'ETHTOOL_MSG_MODULE_SET' and
> 'ETHTOOL_MSG_MODULE_GET', that can be used to control transceiver
> modules parameters and retrieve their status.

Acked-by: Jakub Kicinski <kuba@...nel.org>

Couple of take it or leave it comments again, if you prefer to leave as
is that's fine.

> +enum ethtool_module_power_mode_policy {
> +	ETHTOOL_MODULE_POWER_MODE_POLICY_HIGH,
> +	ETHTOOL_MODULE_POWER_MODE_POLICY_AUTO,
> +};

I see you left this starting from 0, and we still need a valid bit,
granted just internal to the core.

Would we not need a driver-facing valid bit later on when we extend 
the module API to control more params?  Can't there be drivers which
implement power but don't support the mode policy?

> +static int module_set_power_mode(struct net_device *dev, struct nlattr **tb,
> +				 bool *p_mod, struct netlink_ext_ack *extack)
> +{
> +	struct ethtool_module_power_mode_params power = {};
> +	struct ethtool_module_power_mode_params power_new;
> +	const struct ethtool_ops *ops = dev->ethtool_ops;
> +	int ret;
> +
> +	if (!tb[ETHTOOL_A_MODULE_POWER_MODE_POLICY])
> +		return 0;

Feels a little old school to allow set with no attrs, now that we 
do strict validation on attrs across netlink.  What's the reason?

> +	if (!ops->get_module_power_mode || !ops->set_module_power_mode) {
> +		NL_SET_ERR_MSG_ATTR(extack,
> +				    tb[ETHTOOL_A_MODULE_POWER_MODE_POLICY],
> +				    "Setting power mode policy is not supported by this device");
> +		return -EOPNOTSUPP;
> +	}
> +
> +	power_new.policy = nla_get_u8(tb[ETHTOOL_A_MODULE_POWER_MODE_POLICY]);
> +	ret = ops->get_module_power_mode(dev, &power, extack);
> +	if (ret < 0)
> +		return ret;
> +	*p_mod = power_new.policy != power.policy;
> +
> +	return ops->set_module_power_mode(dev, &power_new, extack);

Why still call set if *p_mod == false?