linux-kernel - Re: [PATCH net-next] net: mvpp2: add support for mii

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: <20231206182705.3ff798ad@device.home>
Date:   Wed, 6 Dec 2023 18:27:05 +0100
From:   Maxime Chevallier <maxime.chevallier@...tlin.com>
To:     Stefan Eichenberger <eichest@...il.com>
Cc:     mw@...ihalf.com, linux@...linux.org.uk, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: mvpp2: add support for mii

Hello Stefan,

On Wed,  6 Dec 2023 17:01:25 +0100
Stefan Eichenberger <eichest@...il.com> wrote:

> Currently, mvpp2 only supports RGMII. This commit adds support for MII.
> The description in Marvell's functional specification seems to be wrong.
> To enable MII, we need to set GENCONF_CTRL0_PORT3_RGMII, while for RGMII
> we need to clear it. This is also how U-Boot handles it.
> 
> Signed-off-by: Stefan Eichenberger <eichest@...il.com>
> ---
>  .../net/ethernet/marvell/mvpp2/mvpp2_main.c   | 24 ++++++++++++++++---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 93137606869e..6f136f42e2bf 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -1513,10 +1513,21 @@ static void mvpp22_gop_init_rgmii(struct mvpp2_port *port)
>  	regmap_write(priv->sysctrl_base, GENCONF_PORT_CTRL0, val);
>  
>  	regmap_read(priv->sysctrl_base, GENCONF_CTRL0, &val);
> -	if (port->gop_id == 2)
> +	if (port->gop_id == 2) {
>  		val |= GENCONF_CTRL0_PORT2_RGMII;
> -	else if (port->gop_id == 3)
> +	} else if (port->gop_id == 3) {
>  		val |= GENCONF_CTRL0_PORT3_RGMII_MII;
> +
> +		/* According to the specification, GENCONF_CTRL0_PORT3_RGMII
> +		 * should be set to 1 for RGMII and 0 for MII. However, tests
> +		 * show that it is the other way around. This is also what
> +		 * U-Boot does for mvpp2, so it is assumed to be correct.
> +		 */
> +		if (port->phy_interface == PHY_INTERFACE_MODE_MII)
> +			val |= GENCONF_CTRL0_PORT3_RGMII;
> +		else
> +			val &= ~GENCONF_CTRL0_PORT3_RGMII;
> +	}
>  	regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val);
>  }
>  
> @@ -1615,6 +1626,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port, phy_interface_t interface)
>  		return 0;
>  
>  	switch (interface) {
> +	case PHY_INTERFACE_MODE_MII:
>  	case PHY_INTERFACE_MODE_RGMII:
>  	case PHY_INTERFACE_MODE_RGMII_ID:
>  	case PHY_INTERFACE_MODE_RGMII_RXID:
> @@ -6948,8 +6960,11 @@ static int mvpp2_port_probe(struct platform_device *pdev,
>  					MAC_10000FD;
>  		}
>  
> -		if (mvpp2_port_supports_rgmii(port))
> +		if (mvpp2_port_supports_rgmii(port)) {
>  			phy_interface_set_rgmii(port->phylink_config.supported_interfaces);
> +			__set_bit(PHY_INTERFACE_MODE_MII,
> +				  port->phylink_config.supported_interfaces);
> +		}
>  
>  		if (comphy) {
>  			/* If a COMPHY is present, we can support any of the
> @@ -6973,6 +6988,9 @@ static int mvpp2_port_probe(struct platform_device *pdev,
>  				  port->phylink_config.supported_interfaces);
>  			__set_bit(PHY_INTERFACE_MODE_SGMII,
>  				  port->phylink_config.supported_interfaces);
> +		} else if (phy_mode == PHY_INTERFACE_MODE_MII) {
> +			__set_bit(PHY_INTERFACE_MODE_100BASEX,
> +				  port->phylink_config.supported_interfaces);

Can you explain that part ? I don't understand why 100BaseX is being
reported as a supported mode here. This whole section of the function
is about detecting what can be reported based on the presence or not of
a comphy driver / hardcoded comphy config. I don't think the comphy
here has anything to do with MII / 100BaseX

If 100BaseX can be carried on MII (which I don't know), shouldn't it be
reported no matter what ?

Thanks,

Maxime