netdev - Re: [PATCH net-next 04/11] net: stmmac: add stmmac_get_phy_intf

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: <db01f926-d5bb-4317-beac-e6dcc0025a80@bootlin.com>
Date: Tue, 4 Nov 2025 09:34:31 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
 Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>
Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Fabio Estevam <festevam@...il.com>, imx@...ts.linux.dev,
 Jakub Kicinski <kuba@...nel.org>, Jan Petrous <jan.petrous@....nxp.com>,
 linux-arm-kernel@...ts.infradead.org,
 linux-stm32@...md-mailman.stormreply.com,
 Maxime Coquelin <mcoquelin.stm32@...il.com>, netdev@...r.kernel.org,
 Paolo Abeni <pabeni@...hat.com>,
 Pengutronix Kernel Team <kernel@...gutronix.de>, s32@....com,
 Sascha Hauer <s.hauer@...gutronix.de>, Shawn Guo <shawnguo@...nel.org>
Subject: Re: [PATCH net-next 04/11] net: stmmac: add stmmac_get_phy_intf_sel()

Hi Russell,

On 03/11/2025 12:50, Russell King (Oracle) wrote:
> Provide a function to translate the PHY interface mode to the
> phy_intf_sel pin configuration for dwmac1000 and dwmac4 cores that
> support multiple interfaces. We currently handle MII, GMII, RGMII,
> SGMII, RMII and REVMII, but not TBI, RTBI nor SMII as drivers do not
> appear to use these three and the driver doesn't currently support
> these.
> 
> Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>

First, thanks for this work !

[...]

> +int stmmac_get_phy_intf_sel(phy_interface_t interface)
> +{
> +	int phy_intf_sel = -EINVAL;
> +
> +	if (interface == PHY_INTERFACE_MODE_MII ||
> +	    interface == PHY_INTERFACE_MODE_GMII)
> +		phy_intf_sel = PHY_INTF_SEL_GMII_MII;
> +	else if (phy_interface_mode_is_rgmii(interface))
> +		phy_intf_sel = PHY_INTF_SEL_RGMII;
> +	else if (interface == PHY_INTERFACE_MODE_SGMII)
> +		phy_intf_sel = PHY_INTF_SEL_SGMII;
> +	else if (interface == PHY_INTERFACE_MODE_RMII)
> +		phy_intf_sel = PHY_INTF_SEL_RMII;
> +	else if (interface == PHY_INTERFACE_MODE_REVMII)
> +		phy_intf_sel = PHY_INTF_SEL_REVMII;
> +
> +	return phy_intf_sel;
> +}
> +EXPORT_SYMBOL_GPL(stmmac_get_phy_intf_sel);

Nothng wrong with your code, this is out of curiosity.

I'm wondering how we are going to support cases like socfpga (and
probably some other) where the PHY_INTF_SEL_xxx doesn't directly
translate to the phy_interface, i.e.  when you have a PCS or other
IP that serialises the MAC interface ?

for socfpga for example, we need to set the PHY_INTF_SEL to GMII_MII
when we want to use SGMII / 1000BaseX, but we do set it to RGMII when
we need to output RGMII.

Do you have a plan in mind for that ? (maybe a .get_phy_intf_sel() ops ?)

Maxime