netdev - Re: [PATCH net 2/3] net: dsa: b53: fix configuring RGMII delay on bcm63xx

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: <CAOiHx=mQ8z1CO1V-8b=7pjK-Hm9_4-tcvucKXpM1i+eOOB4axg@mail.gmail.com>
Date: Mon, 19 May 2025 23:43:24 +0200
From: Jonas Gorski <jonas.gorski@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>, Vladimir Oltean <olteanv@...il.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Vivien Didelot <vivien.didelot@...il.com>, Álvaro Fernández Rojas <noltari@...il.com>, 
	Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 2/3] net: dsa: b53: fix configuring RGMII delay on bcm63xx

On Mon, May 19, 2025 at 10:34 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > > These changes look wrong. There is more background here:
> > >
> > > https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
> >
> > This is what makes it work for me (I tested all four modes, rgmii,
> > rgmii-id, rgmii-txid and rgmii-rxid).
>
> So you have rgmii-id which works, and the rest are broken?

I have four rgmii ports with PHYs, I configured each one to a
different mode (rgmii, rgmii-txid, rgmii-rxid, rgmii-id).

Without this change no mode/port works, since there is always either a
0 ns delay or a 4 ns delay in the rx/tx paths (I assume, I have no
equipment to measure).

With this change all modes/ports work. With "rgmii-id" the mac doesn't
configure any delays (and the phy does instead), with "rgmii" it's
vice versa, so there is always the expected 2 ns delay. Same for rxid
and txid.

Though on testing again RGMII_CTRL_TIMING_SEL doesn't seem to be needed.

> > E.g. with a phy-mode of "rgmii-id", both b53 and the PHY driver would
> > enable rx and tx delays, causing the delays to be 4 ns instead of 2
> > ns. So I don't see how this could have ever worked.
>
> In this situation, the switch port is playing the role of MAC. Hence i
> would stick to what is suggested in ethernet-controller.yaml. The MAC
> does not add any delays, and leaves it to the PHY.
> phylink_fwnode_phy_connect() gets the phy-mode from the DT blob, and
> passes it to phylib when it calls phy_attach_direct().
>
> There is a second use case for DSA, when the port is connected to the
> host, i.e. the port is a CPU port. In that setup, the port is playing
> the PHY side of the RGMII connection, with the host conduit interface
> being the MAC. In that setup, the above recommendations is that the
> conduit interface does not add delays, with the expectation the 'PHY'
> adds the delays. Then the DSA port does need to add delays. So you
> might want to use dsa_is_cpu_port() to decide if to add delays or not.

The Switch is always integrated into the host SoC, so there is no
(r)gmii cpu port to configure. There's basically directly attached DMA
to/from the buffers of the cpu port. Not sure if there are even
buffers, or if it is a direct to DMA delivery.

Best Regards,
Jonas