linux-kernel - Re: [PATCH v5 1/2] stmmac: dwmac-mediatek: enable 2ns delay only for special cases

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: <Y6W4vwJHG+6PI8fd@lunn.ch>
Date:   Fri, 23 Dec 2022 15:18:39 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Biao Huang <biao.huang@...iatek.com>
Cc:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...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>,
        Richard Cochran <richardcochran@...il.com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        macpaul.lin@...iatek.com
Subject: Re: [PATCH v5 1/2] stmmac: dwmac-mediatek: enable 2ns delay only for
 special cases

On Fri, Dec 23, 2022 at 09:50:28AM +0800, Biao Huang wrote:
> In current driver, MAC will always enable 2ns delay in RGMII mode,
> but that will lead to transmission failures for "rgmii-id"/"rgmii-txid"
> cases.
> 
> Modify the implementation of fix_mac_speed() to ensure the 2ns delay
> will only take effect for "rgmii-rxid"/"rgmii" cases, then user can
> choose phy-mode freely.

This does not seem correct. There are three ways the delays can be added:

1) The MAC
2) The PHY
3) Extra long lines on the board.

What the four RGMII modes tell you is what is needed in addition to
whatever the board provides. So it describes the combination of 1) and
2). Your board does not appear to be applying any delays, so you
should be using rgmii-id.

The MAC and PHY driver then need to decide how to add these delays,
and in most cases, the MAC does nothing, and passes phy-mode to the
PHY and the PHY adds the delay.

The MAC can add delays, but if it does, it need to mask out the delays
it added to the value passed to the PHY. Otherwise the PHY will add
the delay as well.

>  
> -	if ((phy_interface_mode_is_rgmii(priv_plat->phy_mode))) {
> +	switch (priv_plat->phy_mode) {
> +	case PHY_INTERFACE_MODE_RGMII:
> +	case PHY_INTERFACE_MODE_RGMII_RXID:
>  		/* prefer 2ns fixed delay which is controlled by TXC_PHASE_CTRL,
>  		 * when link speed is 1Gbps with RGMII interface,
>  		 * Fall back to delay macro circuit for 10/100Mbps link speed.

So this is wrong. PHY_INTERFACE_MODE_RGMII means the board is adding
the delay via long lines. You should not be added any delay at all.

For PHY_INTERFACE_MODE_RGMII_RXID, you need to mask the RXID bit from
phy_mode when connecting the MAC to the PHY. Otherwise the PHY is
going to add this delay as well.

	 Andrew