netdev - Re: [PATCH net-next] net: dsa: mark parsed interface mode for legacy switch drivers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdbMYHdNAYdS8u+jtaW8NZ7WkCPYug8Xsb2nQLjPvTxKOg@mail.gmail.com>
Date: Fri, 18 Aug 2023 18:06:01 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>, 
	Heiner Kallweit <hkallweit1@...il.com>, Florian Fainelli <f.fainelli@...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 net-next] net: dsa: mark parsed interface mode for legacy
 switch drivers

On Fri, Aug 18, 2023 at 3:29 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:

> > So skew-delay of 7 steps, each step is ~0.2ns so all pins have a delay
> > of 7*0.2 = 1.4ns.
>
> If I read this correctly, then isn't this 1.4ns delay added not only
> to the RXD and TXD signals, but also RXC and TXC - meaning that although
> there is a delay, the effect is that (e.g.) the relative delay between
> TXC and TXD is zero?

Yes seems like so.

(second instance)

> So here, the skews are:
> - GMAC0 RXD skewed by 7 = 1.4ns, and GMAC0 RXC by 10, making 2ns.
>         Relative skew = 0.6ns.
>
> - GMAC0 TXD by 5 = 1.0ns, and GMAC0 TXD by 10, making 2ns.
>         Relative skew = 1ns.
>
> I think this suggests there's additional skew by the PCB traces to make
> up to the required 1.5 to 2ns skew required by RGMII.

I believe you're right. Also when I looked at that PCB it had a few
swirly traces on it.
https://openwrt.org/_media/media/dlink/dns-313/dns-313-front-large.jpg
Again they seem to be toward the RAM mostly, but I don't know
where these vias go, and clearly the PCB designer is doing some
active work on it.

> As far as I'm concerned, I think I have an overall picture of what is
> going on here - it's whether anyone else agrees with that!
>
> Going back to the 685, the skews for the datalines and clocks are:
>
>         gmac0                          rtl8366rb
>         pinctrl ----- pcb traces ----- pinstrapped
> RXC     1.4ns         unknown          unknown
> RXD*    1.4ns         unknown          unknown
> TXC     1.4ns         unknown          unknown
> TXD*    1.4ns         unknown          unknown
>
> In the case of 313:
>
>         gmac0                          PHY
>         pinctrl ----- pcb traces ----- phy0
> RXC     2.0ns         unknown          0ns      (PHY 0ns due to using
> RXD*    1.4ns         unknown          0ns       phy-mode = "rgmii" on)
> TXC     2.0ns         unknown          0ns       gmac0's node.)
> TXD*    1.0ns         unknown          0ns

Yep that's how it looks.

Yours,
Linus Walleij