linux-kernel - Re: [PATCH RFC net-next v2 14/17] net: stmmac: Move internal PCS PHYLINK ops to stmmac

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: <Zn7Rwt9KNac2mMah@shell.armlinux.org.uk>
Date: Fri, 28 Jun 2024 16:07:46 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Serge Semin <fancer.lancer@...il.com>
Cc: Andrew Halaney <ahalaney@...hat.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Jose Abreu <joabreu@...opsys.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexei Starovoitov <ast@...nel.org>,
	Jesper Dangaard Brouer <hawk@...nel.org>,
	John Fastabend <john.fastabend@...il.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	linux-arm-kernel@...ts.infradead.org,
	linux-stm32@...md-mailman.stormreply.com, bpf@...r.kernel.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC net-next v2 14/17] net: stmmac: Move internal PCS
 PHYLINK ops to stmmac_pcs.c

On Mon, Jun 24, 2024 at 04:26:31PM +0300, Serge Semin wrote:
> @@ -621,7 +548,6 @@ int dwmac1000_setup(struct stmmac_priv *priv)
>  	mac->mii.clk_csr_shift = 2;
>  	mac->mii.clk_csr_mask = GENMASK(5, 2);
>  
> -	mac->mac_pcs.ops = &dwmac1000_mii_pcs_ops;
>  	mac->mac_pcs.neg_mode = true;

"mac->mac_pcs.neg_mode = true;" is a property of the "ops" so should
move with it.

> @@ -1475,7 +1396,6 @@ int dwmac4_setup(struct stmmac_priv *priv)
>  	mac->mii.clk_csr_mask = GENMASK(11, 8);
>  	mac->num_vlan = dwmac4_get_num_vlan(priv->ioaddr);
>  
> -	mac->mac_pcs.ops = &dwmac4_mii_pcs_ops;
>  	mac->mac_pcs.neg_mode = true;

Also applies here.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> index 3666893acb69..c42fb2437948 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> @@ -363,6 +363,7 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
>  		mac->tc = mac->tc ? : entry->tc;
>  		mac->mmc = mac->mmc ? : entry->mmc;
>  		mac->est = mac->est ? : entry->est;
> +		mac->mac_pcs.ops = mac->mac_pcs.ops ?: entry->pcs;

Removing both of the above means that mac->mac_pcs.ops won't ever be set
prior to this, so this whole thing should just be:

		mac->mac_pcs.ops = entry->pcs;
		mac->mac_pcs.neg_mode = true;

> +static void dwmac_pcs_get_state(struct phylink_pcs *pcs,
> +				struct phylink_link_state *state)
>  {
> +	struct mac_device_info *hw = phylink_pcs_to_mac_dev_info(pcs);
>  	struct stmmac_priv *priv = hw->priv;
>  	u32 val;
>  
> +	val = stmmac_pcs_get_config_reg(priv, hw);
> +
> +	/* TODO The next is SGMII/RGMII/SMII-specific */
> +	state->link = !!(val & PCS_CFG_LNKSTS);
> +	if (!state->link)
> +		return;
> +
> +	switch (FIELD_GET(PCS_CFG_LNKSPEED, val)) {
> +	case PCS_CFG_LNKSPEED_2_5:
> +		state->speed = SPEED_10;
> +		break;
> +	case PCS_CFG_LNKSPEED_25:
> +		state->speed = SPEED_100;
> +		break;
> +	case PCS_CFG_LNKSPEED_250:
> +		state->speed = SPEED_1000;
> +		break;
> +	default:
> +		netdev_err(priv->dev, "Unknown speed detected\n");
> +		break;
> +	}
> +
> +	state->duplex = val & PCS_CFG_LNKMOD ? DUPLEX_FULL : DUPLEX_HALF;
> +
> +	/* TODO Check the PCS_AN_STATUS.Link status here?.. Note the flag is latched-low */
> +
> +	/* TODO The next is the TBI/RTBI-specific and seems to be valid if PCS_AN_STATUS.ANC */
>  	val = readl(priv->pcsaddr + PCS_ANE_LPA);

I thought these registers only existed of dma_cap.pcs is true ? If we
start checking PCS_AN_STATUS.Link here, and this register reads as
zeros, doesn't it mean that RMGII inband mode won't ever signal link
up?

>  
> -	/* TODO Make sure that STMMAC_PCS_PAUSE STMMAC_PCS_ASYM_PAUSE usage is legitimate */
> +	/* TODO The databook says the encoding is defined in IEEE 802.3z,
> +	 * Section 37.2.1.4. Do we need the STMMAC_PCS_PAUSE and
> +	 * STMMAC_PCS_ASYM_PAUSE mask here?
> +	 */
>  	linkmode_mod_bit(ETHTOOL_LINK_MODE_Pause_BIT,
>  			 state->lp_advertising,
>  			 FIELD_GET(PCS_ANE_PSE, val) & STMMAC_PCS_PAUSE);

If it's 802.3z aka 1000base-X format, then yes, we should be using
these bits if we are getting state from this register.

If TBI/RTBI is ever used, rather than trying to shoe-horn it all into
these functions, please consider splitting them into separate PCSes,
and sharing code between them e.g. using common functions called from
the method functions or shared method functions where appropriate.

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