All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
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 17:17:20 +0100	[thread overview]
Message-ID: <20250228171720.62c6b378@fedora.home> (raw)
In-Reply-To: <Z8Hf-9yR3qD9cqsX@shell.armlinux.org.uk>

Hi Russell,

On Fri, 28 Feb 2025 16:10:35 +0000
"Russell King (Oracle)" <linux@armlinux.org.uk> wrote:

> 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>

[...]

> > +/**
> > + * 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.

That makes a lot of sense indeed, I will definitely add that.

Thanks a lot for the review,

Maxime


  reply	other threads:[~2025-02-28 16:24 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)
2025-02-28 16:17     ` Maxime Chevallier [this message]
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=20250228171720.62c6b378@fedora.home \
    --to=maxime.chevallier@bootlin.com \
    --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=linux@armlinux.org.uk \
    --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.