netdev - Re: [PATCH net v2] dt-bindings: net: ethernet-controller: Add informative text about RGMII delays

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: <e0e468af-dc5d-4a27-b0b4-dddfef1e7405@lunn.ch>
Date: Thu, 5 Jun 2025 15:20:39 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Icenowy Zheng <uwu@...nowy.me>, Rob Herring <robh@...nel.org>,
	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>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Chaoyi Chen <chaoyi.chen@...k-chips.com>,
	Matthias Schiffer <matthias.schiffer@...tq-group.com>,
	Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2] dt-bindings: net: ethernet-controller: Add
 informative text about RGMII delays

> > > If you want the kernel to not touch the PHY, use
> > > 
> > > phy-mode = 'internal'
> > 
> > This sounds weird, and may introduce side effect on the MAC side.
> > 
> > Well we might need to allow PHY to have phy-mode property in addition
> > to MAC, in this case MAC phy-mode='rgmii*' and PHY phy-mode='internal'
> > might work?
> 
> I'm not convinced that adding more possibilities to the problem (i.o.w.
> the idea that phy=mode = "internal" can be used to avoid the delays
> being messed with) is a good idea - not at this point, because as you
> point out MACs (and PHYs) won't know that they need to be configured
> for RGMII mode. "internal" doesn't state this, and if we do start doing
> this, we'll end up with "internal" selecting RGMII mode which may work
> for some platforms but not all.
> 
> So, IMHO this is a bad idea.

I agree, and if actually see a MAC/PHY pair doing this, i will ask
why. Using "internal" like is currently mostly hypothetical, i don't
actually know of any real users. Those DT blobs which do use
"internal" actually are internal interfaces within a SoC and it is
some vendor proprietary interface which does not need any
configuration. That is the original meaning for "internal", but it has
been noticed it can be used to side step RGMII delay configuration.

It _might_ play a role when developers decide to clean up a mess with
RGMII delays, and decide to just go with the strapping resistors
rather than try to figure out what is actually happening vs what DT
says should be happening, and issue warning the DT blob is out of
date. But still, i would consider "internal" a lazy hack, not a proper
fix.

	Andrew