From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Paul Greenwalt <paul.greenwalt@intel.com>
Cc: <intel-wired-lan@lists.osuosl.org>, <andrew@lunn.ch>,
<aelior@marvell.com>, <manishc@marvell.com>,
<netdev@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v2 2/9] ethtool: Add forced speed to supported link modes maps
Date: Mon, 21 Aug 2023 15:00:08 +0200 [thread overview]
Message-ID: <0ac644c4-e14e-8f41-3e7c-472ec7f7e4a7@intel.com> (raw)
In-Reply-To: <20230819093941.15163-1-paul.greenwalt@intel.com>
From: Paul Greenwalt <paul.greenwalt@intel.com>
Date: Sat, 19 Aug 2023 02:39:41 -0700
> The need to map Ethtool forced speeds to Ethtool supported link modes is
> common among drivers. To support this move the supported link modes maps
> implementation from the qede driver. This is an efficient solution
> introduced in commit 1d4e4ecccb11 ("qede: populate supported link modes
> maps on module init") for qede driver.
[...]
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 62b61527bcc4..245fd4a8d85b 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -1052,4 +1052,78 @@ static inline int ethtool_mm_frag_size_min_to_add(u32 val_min, u32 *val_add,
> * next string.
> */
> extern __printf(2, 3) void ethtool_sprintf(u8 **data, const char *fmt, ...);
> +
> +/* Link mode to forced speed capabilities maps */
> +struct ethtool_forced_speed_map {
> + u32 speed;
> + __ETHTOOL_DECLARE_LINK_MODE_MASK(caps);
> +
> + const u32 *cap_arr;
> + u32 arr_size;
Please re-layout this as follows:
1. caps;
2. cap_arr;
3. arr_size;
4. speed.
Or in any other way that wouldn't provoke holes on 64-bit systems.
I wasn't really familiar with that when initially adding these
definitions :D
> +};
> +
> +#define ETHTOOL_FORCED_SPEED_MAP(value) \
> +{ \
> + .speed = SPEED_##value, \
> + .cap_arr = ethtool_forced_speed_##value, \
> + .arr_size = ARRAY_SIZE(ethtool_forced_speed_##value), \
> +}
> +
> +static const u32 ethtool_forced_speed_1000[] __initconst = {
2 reasons I don't like this:
1. static const in a header file.
This implies code duplication -- every object file will have its own
copy. If we want to reuse them, they should be declared global in one
place (somewhere in net/ethtool), without __initconst unfortunately.
2. __initconst in a header file.
I can refer to that declaration somewhere not in the initialization
code and catch modpost or section reference issues. If we want to
make those global and accessible from the drivers, it should not have
any non-standard section placement.
> + ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
> + ETHTOOL_LINK_MODE_1000baseKX_Full_BIT,
> + ETHTOOL_LINK_MODE_1000baseX_Full_BIT,
BTW, can't we share the target bitmaps instead? I mean, why not
initialize those somewhere in net/ethtool and export them, instead of
exporting the source of initialization?
> +};
> +
> +static const u32 ethtool_forced_speed_10000[] __initconst = {
> + ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
> + ETHTOOL_LINK_MODE_10000baseKR_Full_BIT,
> + ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT,
> + ETHTOOL_LINK_MODE_10000baseR_FEC_BIT,
> + ETHTOOL_LINK_MODE_10000baseCR_Full_BIT,
> + ETHTOOL_LINK_MODE_10000baseSR_Full_BIT,
> + ETHTOOL_LINK_MODE_10000baseLR_Full_BIT,
> + ETHTOOL_LINK_MODE_10000baseLRM_Full_BIT,
> +};
> +
> +static const u32 ethtool_forced_speed_20000[] __initconst = {
> + ETHTOOL_LINK_MODE_20000baseKR2_Full_BIT,
> +};
> +
> +static const u32 ethtool_forced_speed_25000[] __initconst = {
> + ETHTOOL_LINK_MODE_25000baseKR_Full_BIT,
> + ETHTOOL_LINK_MODE_25000baseCR_Full_BIT,
> + ETHTOOL_LINK_MODE_25000baseSR_Full_BIT,
> +};
> +
> +static const u32 ethtool_forced_speed_40000[] __initconst = {
> + ETHTOOL_LINK_MODE_40000baseLR4_Full_BIT,
> + ETHTOOL_LINK_MODE_40000baseKR4_Full_BIT,
> + ETHTOOL_LINK_MODE_40000baseCR4_Full_BIT,
> + ETHTOOL_LINK_MODE_40000baseSR4_Full_BIT,
> +};
> +
> +static const u32 ethtool_forced_speed_50000[] __initconst = {
> + ETHTOOL_LINK_MODE_50000baseKR2_Full_BIT,
> + ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT,
> + ETHTOOL_LINK_MODE_50000baseSR2_Full_BIT,
> +};
> +
> +static const u32 ethtool_forced_speed_100000[] __initconst = {
> + ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT,
> + ETHTOOL_LINK_MODE_100000baseSR4_Full_BIT,
> + ETHTOOL_LINK_MODE_100000baseCR4_Full_BIT,
> + ETHTOOL_LINK_MODE_100000baseLR4_ER4_Full_BIT,
> +};
> +
> +/**
> + * ethtool_forced_speed_maps_init
> + * @maps: Pointer to an array of Ethtool forced speed map
> + * @size: Array size
> + *
> + * Initialize an array of Ethtool forced speed map to Ethtool link modes. This
> + * should be called during driver module init.
> + */
> +void ethtool_forced_speed_maps_init(struct ethtool_forced_speed_map *maps,
> + u32 size);
> #endif /* _LINUX_ETHTOOL_H */
> diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
> index 0b0ce4f81c01..ac1fdd636bc1 100644
> --- a/net/ethtool/ioctl.c
> +++ b/net/ethtool/ioctl.c
> @@ -3388,3 +3388,18 @@ void ethtool_rx_flow_rule_destroy(struct ethtool_rx_flow_rule *flow)
> kfree(flow);
> }
> EXPORT_SYMBOL(ethtool_rx_flow_rule_destroy);
> +
> +void ethtool_forced_speed_maps_init(struct ethtool_forced_speed_map *maps,
> + u32 size)
Alternatively, to avoid passing size here, you can just terminate @maps
array with zeroed element and treat it as the array end.
> +{
> + u32 i;
> +
> + for (i = 0; i < size; i++) {
for (u32 i = 0 ...
> + struct ethtool_forced_speed_map *map = &maps[i];
> +
> + linkmode_set_bit_array(map->cap_arr, map->arr_size, map->caps);
> + map->cap_arr = NULL;
> + map->arr_size = 0;
These two are needed only if your @map really refer to
__initdata/__initconst variables.
> + }
> +}
> +EXPORT_SYMBOL(ethtool_forced_speed_maps_init);
Not sure ioctl.c in the best place for that.
Thanks,
Olek
next prev parent reply other threads:[~2023-08-21 13:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-19 9:39 [PATCH iwl-next v2 2/9] ethtool: Add forced speed to supported link modes maps Paul Greenwalt
2023-08-20 14:45 ` Simon Horman
2023-08-20 17:29 ` Greenwalt, Paul
2023-08-20 18:54 ` Andrew Lunn
2023-08-20 19:20 ` Greenwalt, Paul
2023-08-23 17:56 ` Pawel Chmielewski
2023-08-23 18:09 ` Jacob Keller
2023-08-23 20:58 ` Andrew Lunn
2023-08-25 13:19 ` [Intel-wired-lan] " Alexander Lobakin
2023-08-25 13:47 ` Andrew Lunn
2023-08-25 13:57 ` Alexander Lobakin
2023-08-31 13:08 ` Pawel Chmielewski
2023-09-03 14:00 ` Andrew Lunn
2023-09-04 15:27 ` Pawel Chmielewski
2023-09-14 14:27 ` Pawel Chmielewski
2023-09-15 13:41 ` Alexander Lobakin
2023-09-15 13:58 ` Andrew Lunn
2023-09-15 13:53 ` Andrew Lunn
2023-08-21 13:00 ` Alexander Lobakin [this message]
2023-08-24 10:18 ` kernel test robot
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=0ac644c4-e14e-8f41-3e7c-472ec7f7e4a7@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=aelior@marvell.com \
--cc=andrew@lunn.ch \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=manishc@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=paul.greenwalt@intel.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).