netdev - Re: [PATCH net-next 1/4] dt-bindings: net: ethernet-controller: update descriptions of RGMII modes

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: <d79ed229-f0b7-441a-b075-31fd2b2f8fe6@lunn.ch>
Date: Tue, 22 Apr 2025 16:40:25 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Matthias Schiffer <matthias.schiffer@...tq-group.com>,
	Siddharth Vadapalli <s-vadapalli@...com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Andy Whitcroft <apw@...onical.com>,
	Dwaipayan Ray <dwaipayanray1@...il.com>,
	Lukas Bulwahn <lukas.bulwahn@...il.com>,
	Joe Perches <joe@...ches.com>, Jonathan Corbet <corbet@....net>,
	Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
	Roger Quadros <rogerq@...nel.org>, Tero Kristo <kristo@...nel.org>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux@...tq-group.com
Subject: Re: [PATCH net-next 1/4] dt-bindings: net: ethernet-controller:
 update descriptions of RGMII modes

> I'm hoping that Andrew will read my email form yesterday and reconsider
> because to me this is a backwards step

I will get back to that in a minute.

> > On Linux, there currently isn't a way for the MAC driver to query from the PHY
> > whether it could include the delays itself. My assumption is that most PHYs
> > either don't have internal delays, or the delays are configurable.
> 
> motorcomm, dp83tg720, icplus, marvell, dp 838678, adin, micrel, tja11xx,
> vitesse, dp83822, mscc, at803x, microchip_t1, broadcom, dp83869,
> intel-xway, realtek all do handle internal delays. I haven't checked
> whether there are PHYs that don't - that's harder because we don't know
> whether PHYs that don't mention RGMII in the driver actually support
> RGMII or not.

I did look through this once. There are no PHYs with Linux drivers
which support any of the RGMII without supporting all 4 RGMII
modes. So we should just assume all RGMII PHYs can add the delays.

If i remember the history correctly, Renesas built an RDK with a PHY
which did not support RGMII delays. So they where forced to do the
delays in the MAC. But it seems like mainline support for that PHY
never happened.

> 
> > If this is
> > the case, having the MAC add them in internal-delay modes and not adding them on
> > the PHY side would be the best default (also for PHY-less/fixed-link setups,
> > which should be handled like a PHY without internal delay capabilities.)
> 
> See my "advanced" use case above. We do have drivers doing that.

I agree with Russell here, it is the worse default, not the best
default. It makes it different to nearly every other MAC driver. It
needs extra work in the MAC, which most MAC drivers get wrong. They
also tend not to call out they have done it different to every other
MAC driver in Linux, and so it does not get the needed extra review,
and so is broken. I also think there is some 'vendor SDK' mentality
here. Our MAC can do this, our SDK allows it, the Linux driver must
have it and use it. Pretty much all hardware has features which never
get used, but vendors sometimes have issues with just leaving it
unused.

	Andrew