linux-kernel - Re: [PATCH net-next 05/13] net: phy: Create a phy

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: <20250212165958.6baaf294@fedora.home>
Date: Wed, 12 Feb 2025 16:59:58 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: davem@...emloft.net
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, thomas.petazzoni@...tlin.com, Andrew Lunn
 <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Russell King
 <linux@...linux.org.uk>, linux-arm-kernel@...ts.infradead.org, Christophe
 Leroy <christophe.leroy@...roup.eu>, Herve Codina
 <herve.codina@...tlin.com>, Florian Fainelli <f.fainelli@...il.com>, Heiner
 Kallweit <hkallweit1@...il.com>, Vladimir Oltean <vladimir.oltean@....com>,
 Köry Maincent <kory.maincent@...tlin.com>, Marek
 Behún <kabel@...nel.org>, Oleksij Rempel
 <o.rempel@...gutronix.de>, Nicolò Veronese
 <nicveronese@...il.com>, Simon Horman <horms@...nel.org>,
 mwojtas@...omium.org, Antoine Tenart <atenart@...nel.org>,
 devicetree@...r.kernel.org, Conor Dooley <conor+dt@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>, Romain
 Gantois <romain.gantois@...tlin.com>
Subject: Re: [PATCH net-next 05/13] net: phy: Create a phy_port for
 PHY-driven SFPs

On Fri,  7 Feb 2025 23:36:24 +0100
Maxime Chevallier <maxime.chevallier@...tlin.com> wrote:

> Some PHY devices may be used as media-converters to drive SFP ports (for
> example, to allow using SFP when the SoC can only output RGMII). This is
> already supported to some extend by allowing PHY drivers to registers
> themselves as being SFP upstream.
> 
> However, the logic to drive the SFP can actually be split to a per-port
> control logic, allowing support for multi-port PHYs, or PHYs that can
> either drive SFPs or Copper.
> 
> To that extent, create a phy_port when registering an SFP bus onto a
> PHY. This port is considered a "serdes" port, in that it can feed data
> to anther entity on the link. The PHY driver needs to specify the
> various PHY_INTERFACE_MODE_XXX that this port supports.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier@...tlin.com>
[...]
>  
> +/**
> + * phylink_interfaces_to_linkmodes() - List all possible linkmodes based on a
> + *				       set of supported interfaces, assuming no
> + *				       rate matching.
> + * @linkmodes: the supported linkmodes
> + * @interfaces: Set of interfaces (PHY_INTERFACE_MODE_XXX)
> + *
> + * Compute the exhaustive list of modes that can conceivably be achieved from a
> + * set of MII interfaces. This is derived from the possible speeds and duplex
> + * achievable from these interfaces. This list is likely too exhaustive (there
> + * may not exist any device out there that can convert from an interface to a
> + * linkmode) and it needs further filtering based on real HW capabilities.
> + */
> +void phylink_interfaces_to_linkmodes(unsigned long *linkmodes,
> +				     const unsigned long *interfaces)
> +{
> +	phy_interface_t interface;
> +	unsigned long caps = 0;
> +
> +	linkmode_zero(linkmodes);
> +
> +	for_each_set_bit(interface, interfaces, PHY_INTERFACE_MODE_MAX)
> +		caps = phylink_get_capabilities(interface,
> +						GENMASK(__fls(MAC_400000FD),
> +							__fls(MAC_10HD)),
> +						RATE_MATCH_NONE);

Shoule be :
		caps |= phylink_get_capabilities(...);

I'll address that in V2, my bad...

Maxime