netdev - Re: [PATCH RFC net-next 4/4] net: xpcs: allow 1000BASE-X to work with older XPCS IP

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: <20250210110555.stuowh5l6hmz2yxh@skbuf>
Date: Mon, 10 Feb 2025 13:05:55 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>
Cc: Tristram.Ha@...rochip.com, UNGLinuxDriver@...rochip.com,
	Woojung Huh <woojung.huh@...rochip.com>,
	Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org
Subject: Re: [PATCH RFC net-next 4/4] net: xpcs: allow 1000BASE-X to work
 with older XPCS IP

On Wed, Feb 05, 2025 at 01:27:47PM +0000, Russell King (Oracle) wrote:
> Older XPCS IP requires SGMII_LINK and PHY_SIDE_SGMII to be set when
> operating in 1000BASE-X mode even though the XPCS is not configured for
> SGMII. An example of a device with older XPCS IP is KSZ9477.
> 
> We already don't clear these bits if we switch from SGMII to 1000BASE-X
> on TXGBE - which would result in 1000BASE-X with the PHY_SIDE_SGMII bit
> left set.

Is there a confirmation written down somewhere that a transition from
SGMII to 1000Base-X was explicitly tested? I have to remain a bit
skeptical and say that although the code is indeed like this, it
doesn't mean by itself there are no unintended side effects.

> It is currently believed to be safe to set both bits on newer IP
> without side-effects.
> 
> Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> ---
>  drivers/net/pcs/pcs-xpcs.c | 13 +++++++++++--
>  drivers/net/pcs/pcs-xpcs.h |  1 +
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
> index 1eba0c583f16..d522e4a5a138 100644
> --- a/drivers/net/pcs/pcs-xpcs.c
> +++ b/drivers/net/pcs/pcs-xpcs.c
> @@ -774,9 +774,18 @@ static int xpcs_config_aneg_c37_1000basex(struct dw_xpcs *xpcs,
>  			return ret;
>  	}
>  
> -	mask = DW_VR_MII_PCS_MODE_MASK;
> +	/* Older XPCS IP requires PHY_MODE (bit 3) and SGMII_LINK (but 4) to
                                                                   ~~~
                                                                   bit

> +	 * be set when operating in 1000BASE-X mode. See page 233
> +	 * https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/KSZ9477S-Data-Sheet-DS00002392C.pdf
> +	 * "5.5.9 SGMII AUTO-NEGOTIATION CONTROL REGISTER"
> +	 */
> +	mask = DW_VR_MII_PCS_MODE_MASK | DW_VR_MII_AN_CTRL_SGMII_LINK |
> +	       DW_VR_MII_TX_CONFIG_MASK;
>  	val = FIELD_PREP(DW_VR_MII_PCS_MODE_MASK,
> -			 DW_VR_MII_PCS_MODE_C37_1000BASEX);
> +			 DW_VR_MII_PCS_MODE_C37_1000BASEX) |
> +	      FIELD_PREP(DW_VR_MII_TX_CONFIG_MASK,
> +			 DW_VR_MII_TX_CONFIG_PHY_SIDE_SGMII) |
> +	      DW_VR_MII_AN_CTRL_SGMII_LINK;
>  
>  	if (!xpcs->pcs.poll) {
>  		mask |= DW_VR_MII_AN_INTR_EN;

I do believe that this is the kind of patch one would write when the
hardware is completely a black box. But when we have Microchip engineers
here with a channel open towards their hardware design who can help
clarify where the requirement comes from, that just isn't the case.
So I wouldn't rush with this.

Plus, it isn't even the most conservative way in which a (supposedly)
integration-specific requirement is fulfilled in the common Synopsys
driver. If one integration makes vendor-specific choices about these
bits, I wouldn't assume that no other vendors made contradictory choices.

I don't want to say too much before Tristram comes with a statement from
Microchip hardware design, but _if_ it turns out to be a KSZ9477
specific requirement, it still seems safer to only enable this based
(at least) on Tristram's MICROCHIP_KSZ9477_PMA_ID conditional from his
other patch set, if not based on something stronger (a conditional
describing some functional behavior, rather than a specific hardware IP).