From: Michal Kubecek <mkubecek@suse.cz>
To: netdev@vger.kernel.org
Cc: Cris Forno <cforno12@linux.vnet.ibm.com>,
mst@redhat.com, jasowang@redhat.com, haiyangz@microsoft.com,
sthemmin@microsoft.com, sashal@kernel.org,
tlfalcon@linux.ibm.com, davem@davemloft.net,
willemdebruijn.kernel@gmail.com, kuba@kernel.org
Subject: Re: [PATCH, net-next, v5, 1/2] ethtool: Factored out similar ethtool link settings for virtual devices to core
Date: Fri, 21 Feb 2020 18:49:34 +0100 [thread overview]
Message-ID: <20200221174934.GC5607@unicorn.suse.cz> (raw)
In-Reply-To: <20200218175227.8511-2-cforno12@linux.vnet.ibm.com>
On Tue, Feb 18, 2020 at 11:52:26AM -0600, Cris Forno wrote:
> Three virtual devices (ibmveth, virtio_net, and netvsc) all have
> similar code to get link settings and validate ethtool command. To
> eliminate duplication of code, it is factored out into core/ethtool.c.
>
> Signed-off-by: Cris Forno <cforno12@linux.vnet.ibm.com>
> ---
> include/linux/ethtool.h | 8 ++++++++
> net/ethtool/ioctl.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 53 insertions(+)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 95991e43..fbc38f0 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -420,4 +420,12 @@ struct ethtool_rx_flow_rule *
> ethtool_rx_flow_rule_create(const struct ethtool_rx_flow_spec_input *input);
> void ethtool_rx_flow_rule_destroy(struct ethtool_rx_flow_rule *rule);
>
> +bool ethtool_virtdev_validate_cmd(const struct ethtool_link_ksettings *cmd);
> +int ethtool_virtdev_set_link_ksettings(struct net_device *dev,
> + const struct ethtool_link_ksettings *cmd,
> + u32 *dev_speed, u8 *dev_duplex,
> + bool (*ethtool_virtdev_validate_cmd)
> + (const struct ethtool_link_ksettings *));
Using the same argument name as the default function used for it is
rather confusing.
Using a typedef for the type might make the declaration a bit easier to
read.
> +
> +
> #endif /* _LINUX_ETHTOOL_H */
> diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
> index b987052..173e083 100644
> --- a/net/ethtool/ioctl.c
> +++ b/net/ethtool/ioctl.c
> @@ -459,6 +459,25 @@ static int load_link_ksettings_from_user(struct ethtool_link_ksettings *to,
> return 0;
> }
>
> +/* Check if the user is trying to change anything besides speed/duplex */
> +bool ethtool_virtdev_validate_cmd(const struct ethtool_link_ksettings *cmd)
> +{
> + struct ethtool_link_settings base2 = {};
> +
> + base2.speed = cmd->base.speed;
> + base2.port = PORT_OTHER;
> + base2.duplex = cmd->base.duplex;
> + base2.cmd = cmd->base.cmd;
> + base2.link_mode_masks_nwords = cmd->base.link_mode_masks_nwords;
These could go into the initialization but I guess it's a matter of
taste.
> + return !memcmp(&base2, &cmd->base, sizeof(base2)) &&
> + bitmap_empty(cmd->link_modes.supported,
> + __ETHTOOL_LINK_MODE_MASK_NBITS) &&
> + bitmap_empty(cmd->link_modes.lp_advertising,
> + __ETHTOOL_LINK_MODE_MASK_NBITS);
> +}
> +EXPORT_SYMBOL(ethtool_virtdev_validate_cmd);
> +
> /* convert a kernel internal ethtool_link_ksettings to
> * ethtool_link_usettings in user space. return 0 on success, errno on
> * error.
> @@ -581,6 +600,32 @@ static int ethtool_set_link_ksettings(struct net_device *dev,
> return err;
> }
>
> +int ethtool_virtdev_set_link_ksettings(struct net_device *dev,
> + const struct ethtool_link_ksettings *cmd,
> + u32 *dev_speed, u8 *dev_duplex,
> + bool (*dev_virtdev_validate_cmd)
> + (const struct ethtool_link_ksettings *))
The argument is named different than in the declaration which is also
a bit confusing.
> +{
> + bool (*validate)(const struct ethtool_link_ksettings *);
> + u32 speed;
> + u8 duplex;
> +
> + validate = dev_virtdev_validate_cmd ? dev_virtdev_validate_cmd :
> + ethtool_virtdev_validate_cmd;
This can be shortened to
validate = dev_virtdev_validate_cmd ?: ethtool_virtdev_validate_cmd;
The only thing I really don't like is the confusing naming of handler
argument (different between declaration and definition and one of them
conflicting with function used as default for that argument). The rest
is just nitpicking.
Michal Kubecek
> + speed = cmd->base.speed;
> + duplex = cmd->base.duplex;
> + /* don't allow custom speed and duplex */
> + if (!ethtool_validate_speed(speed) ||
> + !ethtool_validate_duplex(duplex) ||
> + !(*validate)(cmd))
> + return -EINVAL;
> + *dev_speed = speed;
> + *dev_duplex = duplex;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(ethtool_virtdev_set_link_ksettings);
> +
> /* Query device for its ethtool_cmd settings.
> *
> * Backward compatibility note: for compatibility with legacy ethtool, this is
> --
> 1.8.3.1
>
next prev parent reply other threads:[~2020-02-21 17:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 17:52 [PATCH, net-next, v5, 0/2] net/ethtool: Introduce link_ksettings API for virtual network devices Cris Forno
2020-02-18 17:52 ` [PATCH, net-next, v5, 1/2] ethtool: Factored out similar ethtool link settings for virtual devices to core Cris Forno
2020-02-21 17:49 ` Michal Kubecek [this message]
2020-02-18 17:52 ` [PATCH, net-next, v5, 2/2] net/ethtool: Introduce link_ksettings API for virtual network devices Cris Forno
2020-02-21 18:16 ` Michal Kubecek
2020-02-25 21:33 ` Cris Forno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200221174934.GC5607@unicorn.suse.cz \
--to=mkubecek@suse.cz \
--cc=cforno12@linux.vnet.ibm.com \
--cc=davem@davemloft.net \
--cc=haiyangz@microsoft.com \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=sthemmin@microsoft.com \
--cc=tlfalcon@linux.ibm.com \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).