linux-kernel - Re: [PATCH v2 2/2] ARM: dts: aspeed: Add NVIDIA VR144NVL board

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] [day] [month] [year] [list]

Message-ID: <ae46aa8e57d01208deb56a8fd01f26a9a0bf359b.camel@codeconstruct.com.au>
Date: Mon, 15 Sep 2025 14:04:19 +0930
From: Andrew Jeffery <andrew@...econstruct.com.au>
To: Donald Shannon <donalds@...dia.com>, robh@...nel.org,
 krzk+dt@...nel.org, 	conor+dt@...nel.org, Andrew Lunn <andrew@...n.ch>
Cc: joel@....id.au, devicetree@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-aspeed@...ts.ozlabs.org, 
	linux-kernel@...r.kernel.org, openbmc@...ts.ozlabs.org, etanous@...dia.com
Subject: Re: [PATCH v2 2/2] ARM: dts: aspeed: Add NVIDIA VR144NVL board

Hi Donald,

On Wed, 2025-09-10 at 09:46 -0700, Donald Shannon wrote:
> On 9/9/25 16:05, Donald Shannon wrote:
> > On 9/3/25 00:07, Andrew Jeffery wrote:
> > 
> > > Hi Donald,
> > > 
> > > On Fri, 2025-08-22 at 13:38 -0700, Donald Shannon wrote:
> > > > This is an Aspeed AST2600 based BMC board for the NVIDIA VR144NVL
> > > > Platform.
> > > > 

*snip*

> > > > +
> > > > +&mdio0 {
> > > > +       status = "okay";
> > > > +       ethphy0: ethernet-phy@0 {
> > > > +               compatible = "ethernet-phy-ieee802.3-c22";
> > > > +               reg = <0>;
> > > > +       };
> > > > +};
> > > > +
> > > > +&mac0 {
> > > > +       pinctrl-names = "default";
> > > > +       phy-mode = "rgmii-id"; 
> > > Is this correct, in the context of the query here?
> > > 
> > > https://lore.kernel.org/all/6a3d7eb4-c091-437f-98f8-2b8577e539a7@lunn.ch/
> > > 
> > > If not, please drop the node from the patch until the MAC driver is
> > > fixed with respect to the RGMII delays.
> > > 
> > > Andrew 
> > 
> > Hi Andrew,
> > 
> > I will change this to alphabetical order.
> > 
> > The extra space in our flash is for root of trust application. I will note this in the next patch.
> > 
> > I see that the ftgmac100 drivers do not use the phy-mode parameter so I will leave it out.
> > 
> > Thanks,
> > Don
> > 
> 
> Hi Andrew,
> 
> I am getting conflicting messages in my v3 patch series and want to confirm what the consensus
> is for removing or keeping the unused phy-mode parameter.
> 

The background is that there's been some concerns over phy-mode wrt to
where the RGMII delays are inserted, and the impact on the phy
configuration. My intent was that if you were unsure that you would
remove the entire mac node rather than just the phy-mode property. That
way there's no networking that can break when ASPEED sort out issues
with the ftgmac100 driver. You would have to carry a downstream patch
to add the node back for networking, but I feel that's an improvement
on carrying the entire devicetree downstream.

However:

>  There is some inconsistency in
> the existing dts-es as well.

Yes, this is part of the problem.

> 
> Our board phy implements tx and rx delay, so -id would be the appropriate one to use if we
> decide to use it.

Right, so long as there's no delay configured for the MAC in the SCU
(see SCU340-35C) and networking functions for your board then I think
it's fine to keep the node and specify `phy-mode = "rgmii-id";`. Any
fixes to the driver shouldn't break that arrangement (as in this
configuration it should deconfigure any delays for the MAC in the SCU).

There's some good documentation here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/ethernet-controller.yaml?h=v6.16#n264

and relevant discussion here:

https://lore.kernel.org/all/f28736b5-f4e4-488e-8c9b-55afc7316c5e@lunn.ch/

Sorry for the confusion.

Andrew