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]

Date: Wed, 8 May 2024 13:07:29 +0200
From: Niklas Söderlund <niklas.soderlund+renesas@...natech.se>
To: Andrew Lunn <andrew@...n.ch>
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

On 2024-05-08 02:35:27 +0200, Andrew Lunn wrote:
> > > 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.

Thanks for your patience and this explanation, I understand now.

> 
> > 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

-- 
Kind Regards,
Niklas Söderlund