All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: davem@davemloft.net, "Andrew Lunn" <andrew@lunn.ch>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Eric Dumazet" <edumazet@google.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	thomas.petazzoni@bootlin.com,
	linux-arm-kernel@lists.infradead.org,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Herve Codina" <herve.codina@bootlin.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Vladimir Oltean" <vladimir.oltean@nxp.com>,
	"Köry Maincent" <kory.maincent@bootlin.com>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>,
	"Simon Horman" <horms@kernel.org>,
	"Romain Gantois" <romain.gantois@bootlin.com>
Subject: Re: [PATCH net-next v3 03/13] net: phy: phy_caps: Move phy_speeds to phy_caps
Date: Fri, 28 Feb 2025 16:10:35 +0000	[thread overview]
Message-ID: <Z8Hf-9yR3qD9cqsX@shell.armlinux.org.uk> (raw)
In-Reply-To: <20250228145540.2209551-4-maxime.chevallier@bootlin.com>

On Fri, Feb 28, 2025 at 03:55:28PM +0100, Maxime Chevallier wrote:
> Use the newly introduced link_capabilities array to derive the list of
> possible speeds when given a combination of linkmodes. As
> link_capabilities is indexed by speed, we don't have to iterate the
> whole phy_settings array.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
>  drivers/net/phy/phy-caps.h |  3 +++
>  drivers/net/phy/phy-core.c | 15 ---------------
>  drivers/net/phy/phy.c      |  3 ++-
>  drivers/net/phy/phy_caps.c | 27 +++++++++++++++++++++++++++
>  include/linux/phy.h        |  2 --
>  5 files changed, 32 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/net/phy/phy-caps.h b/drivers/net/phy/phy-caps.h
> index 846d483269f6..f8cdfdb09242 100644
> --- a/drivers/net/phy/phy-caps.h
> +++ b/drivers/net/phy/phy-caps.h
> @@ -41,4 +41,7 @@ struct link_capabilities {
>  
>  void phy_caps_init(void);
>  
> +size_t phy_caps_speeds(unsigned int *speeds, size_t size,
> +		       unsigned long *linkmodes);
> +
>  #endif /* __PHY_CAPS_H */
> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
> index b1c1670de23b..8533e57c3500 100644
> --- a/drivers/net/phy/phy-core.c
> +++ b/drivers/net/phy/phy-core.c
> @@ -339,21 +339,6 @@ phy_lookup_setting(int speed, int duplex, const unsigned long *mask, bool exact)
>  }
>  EXPORT_SYMBOL_GPL(phy_lookup_setting);
>  
> -size_t phy_speeds(unsigned int *speeds, size_t size,
> -		  unsigned long *mask)
> -{
> -	size_t count;
> -	int i;
> -
> -	for (i = 0, count = 0; i < ARRAY_SIZE(settings) && count < size; i++)
> -		if (settings[i].bit < __ETHTOOL_LINK_MODE_MASK_NBITS &&
> -		    test_bit(settings[i].bit, mask) &&
> -		    (count == 0 || speeds[count - 1] != settings[i].speed))
> -			speeds[count++] = settings[i].speed;
> -
> -	return count;
> -}
> -
>  static void __set_linkmode_max_speed(u32 max_speed, unsigned long *addr)
>  {
>  	const struct phy_setting *p;
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 16ffc00b419c..3128df03feda 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -37,6 +37,7 @@
>  #include <net/sock.h>
>  
>  #include "phylib-internal.h"
> +#include "phy-caps.h"
>  
>  #define PHY_STATE_TIME	HZ
>  
> @@ -245,7 +246,7 @@ unsigned int phy_supported_speeds(struct phy_device *phy,
>  				  unsigned int *speeds,
>  				  unsigned int size)
>  {
> -	return phy_speeds(speeds, size, phy->supported);
> +	return phy_caps_speeds(speeds, size, phy->supported);
>  }
>  
>  /**
> diff --git a/drivers/net/phy/phy_caps.c b/drivers/net/phy/phy_caps.c
> index 367ca7110ddc..e5c716365b36 100644
> --- a/drivers/net/phy/phy_caps.c
> +++ b/drivers/net/phy/phy_caps.c
> @@ -76,3 +76,30 @@ void phy_caps_init(void)
>  		__set_bit(i, link_caps[capa].linkmodes);
>  	}
>  }
> +
> +/**
> + * phy_caps_speeds() - Fill an array of supported SPEED_* values for given modes
> + * @speeds: Output array to store the speeds list into
> + * @size: Size of the output array
> + * @linkmodes: Linkmodes to get the speeds from
> + *
> + * Fills the speeds array with all possible speeds that can be achieved with
> + * the specified linkmodes.
> + *
> + * Returns: The number of speeds filled into the array. If the input array isn't
> + *	    big enough to store all speeds, fill it as much as possible.
> + */
> +size_t phy_caps_speeds(unsigned int *speeds, size_t size,
> +		       unsigned long *linkmodes)
> +{
> +	size_t count;
> +	int capa;
> +
> +	for (capa = 0, count = 0; capa < __LINK_CAPA_MAX && count < size; capa++) {
> +		if (linkmode_intersects(link_caps[capa].linkmodes, linkmodes) &&
> +		    (count == 0 || speeds[count - 1] != link_caps[capa].speed))
> +			speeds[count++] = link_caps[capa].speed;
> +	}

Having looked at several of these patches, there's a common pattern
emerging, which is we're walking over link_caps in either ascending
speed order or descending speed order. So I wonder whether it would
make sense to have:

#define for_each_link_caps_asc_speed(cap) \
	for (cap = link_caps; cap < &link_caps[__LINK_CAPA_MAX]; cap++)
#define for_each_link_caps_desc_speed(cap) \
	for (cap = &link_caps[__LINK_CAPA_MAX - 1]; cap >= link_caps; cap--)

for where iterating over in speed order is important. E.g. this would
make the above:

	struct link_capabilities *lcap;

	for_each_link_caps_asc_speed(lcap)
		if (linkmode_intersects(lcap->linkmodes, linkmodes) &&
		    (count == 0 || speeds[count - 1] != lcap->speed)) {
			speeds[count++] = lcap->speed;
			if (count >= size)
				break;
		}

which helps to make it explicit that speeds[] is in ascending value
order.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2025-02-28 16:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-28 14:55 [PATCH net-next v3 00/13] net: phy: Rework linkmodes handling in a dedicated file Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 01/13] net: ethtool: Export the link_mode_params definitions Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 02/13] net: phy: Use an internal, searchable storage for the linkmodes Maxime Chevallier
2025-02-28 15:41   ` Russell King (Oracle)
2025-02-28 15:55     ` Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 03/13] net: phy: phy_caps: Move phy_speeds to phy_caps Maxime Chevallier
2025-02-28 16:10   ` Russell King (Oracle) [this message]
2025-02-28 16:17     ` Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 04/13] net: phy: phy_caps: Move __set_linkmode_max_speed " Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 05/13] net: phy: phy_caps: Introduce phy_caps_valid Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 06/13] net: phy: phy_caps: Implement link_capabilities lookup by linkmode Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 07/13] net: phy: phy_caps: Allow looking-up link caps based on speed and duplex Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 08/13] net: phy: phy_device: Use link_capabilities lookup for PHY aneg config Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 09/13] net: phylink: Use phy_caps_lookup for fixed-link configuration Maxime Chevallier
2025-02-28 16:20   ` Russell King (Oracle)
2025-02-28 16:49     ` Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 10/13] net: phy: drop phy_settings and the associated lookup helpers Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 11/13] net: phylink: Add a mapping between MAC_CAPS and LINK_CAPS Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 12/13] net: phylink: Convert capabilities to linkmodes using phy_caps Maxime Chevallier
2025-02-28 14:55 ` [PATCH net-next v3 13/13] net: phy: phy_caps: Allow getting an phy_interface's capabilities Maxime Chevallier

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=Z8Hf-9yR3qD9cqsX@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=christophe.leroy@csgroup.eu \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=herve.codina@bootlin.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=romain.gantois@bootlin.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vladimir.oltean@nxp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.