netdev - Re: [net-next,v2] net: ethernet: rtsn: Add support for Renesas Ethernet-TSN

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: <2cd13d49-6b9f-4ce8-ba4e-ca02b4568842@lunn.ch>
Date: Wed, 8 May 2024 02:35:27 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Niklas Söderlund <niklas.soderlund+renesas@...natech.se>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.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, linux-renesas-soc@...r.kernel.org
Subject: Re: [net-next,v2] net: ethernet: rtsn: Add support for Renesas
 Ethernet-TSN

> > This looks wrong. You should be applying delays for rgmii-id and
> > rgmii-rxid. Plain rgmii means no delays are required, because the
> > board has extra long clock lines. Same for TX delays, only for
> > rgmii-tx or rgmii-id.
> 
> This confuses me a bit, from the bindings in ethernet-controller.yaml I 
> get this the other way around,
> 
>       # RX and TX delays are added by the MAC when required
>       - rgmii
> 
>       # RGMII with internal RX and TX delays provided by the PHY,
>       # the MAC should not add the RX or TX delays in this case
>       - rgmii-id
> 
>       # RGMII with internal RX delay provided by the PHY, the MAC
>       # should not add an RX delay in this case
>       - rgmii-rxid
> 
>       # RGMII with internal TX delay provided by the PHY, the MAC
>       # should not add an TX delay in this case
>       - rgmii-txid
> 
> The way I understand it is that if if the phy-mode is 'rgmii' the MAC 
> shall apply delays if requested and only if the phy-mode is 'rgmii-id' 
> shall the MAC completely ignore the delays and let the PHY handle it.

It is confusing, and made worse by you doing different to normal and
implementing it in the MAC, not the PHY.

1% of boards use extra long clock lines, so don't need additional
delays. They use 'rgmii'. There is at least one board i know of which
has one extra long clock line, and one normal length clock line. That
board uses 'rgmii-txid', or 'rgmii-rxid', i don't remember which. The
other 98% of boards should be using 'rgmii-id', indicating something
needs to insert delays.  Of those 98%, the vast majority pass phy-mode
straight to the PHY, and the PHY added delays in both the Rx and Tx
clock. If the MAC decides to add the delays, and it is 'rgmii-id', it
should enable delays for both clock lines, and pass 'rgmii' to the
PHY. In the unlikely event somebody builds one of those 2% boards
using the MAC, you need to enable just Rx delays, or just Tx delays,
or maybe no delay at all, because of extra long clock lines. But you
should still be passing 'rgmii' to the PHY.

> Just so I understand correctly, if the phy-mode is A I should pass B to 
> of_phy_connect() if I apply the delays in the MAC.
> 
> A               B
> rgmii           rgmii-id
> rgmii-id        rgmii
> rgmii-rxid      rgmii-txid
> rgmii-txid      rgmii-rxid

Nope. Since the MAC is doing the delay, you always pass rgmii to the
PHY. A determines what, if any, delays the MAC adds.

     Andrew