[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK+owog-Mipq2Oc0=gd8+LziHmVUrC5R7HidYYZWu9_AWu02TA@mail.gmail.com>
Date: Wed, 4 Jun 2025 17:20:56 +0200
From: Stefano Radaelli <stefano.radaelli21@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>, imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [v1] arm64: dts: freescale: imx93-var-som: update eqos support
for MaxLinear PHY
Hi Andrew,
Absolutely, thanks again for pointing this out! I'm actually glad you asked,
because it pushed me to double-check internally with our hardware team
and confirm the exact implementation details.
I'll make sure to include a proper comment in the device tree right above the
'phy-mode = "rgmii";' line in v2, clearly stating that the RGMII delays are
handled via fixed passive components on the SOM's PCB itself, with no
software or strap-based configuration involved.
Thanks again,
Stefano
Il giorno mer 4 giu 2025 alle ore 17:13 Andrew Lunn <andrew@...n.ch> ha scritto:
>
> On Wed, Jun 04, 2025 at 03:08:09PM +0200, Stefano Radaelli wrote:
> > Hi Andrew,
> >
> > To clarify more precisely: hw team told me that the required 2 ns
> > RGMII delays are
> > implemented directly in hardware inside the SOM itself, through passive delay
> > elements (filters) placed on the RX and TX lines. There is no reliance on PHY
> > strap settings or any kind of delay configuration via registers.
> >
> > This means:
> > - The delays are fixed and cannot be changed via software.
> > - From the point of view of any carrier board, the interface is
> > already timing-compliant.
>
> Great. Please add a comment in the DT explaining this. 99% of the time
> 'rgmii' is wrong, but this is the 1%. We should make it clear this is
> not just another cut/paste error, but very intentional and correct
> because of the PCB design.
>
> There is a patch to checkpatch.pl i want to introduce in the next
> development cycle which will look for 'rgmii', and if found, look on
> the line before for a comment including the word 'PCB'. If it finds
> 'rgmii' without such a comment it will issue a warning. So it would be
> nice to avoid that in your correct case.
>
> Andrew
Powered by blists - more mailing lists