Re: [PATCH v3 2/2] ARM: dts: aspeed: Add NVIDIA VR-NVL BMC

On Wed, 2026-07-22 at 10:21 +0200, Krzysztof Kozlowski wrote:
> On 22/07/2026 09:45, Andrew Jeffery wrote:
> > Hi Jacky,
> >=20
> > On Fri, 2026-07-10 at 14:46 +0900, Jacky Huang wrote:
> > > Add the device tree for the Aspeed AST2600 BMC for NVIDIA's Vera
> > > Rubin NVL compute platform.
> > >=20
> > > MAC0 uses phy-mode =3D "rgmii-id" because the on-board PHY supplies
> > > both RGMII internal delays.=C2=A0 The matching U-Boot device tree doe=
s not
> > > enable SoC-side MAC clock delays, leaving the MAC internal delay at
> > > zero so the PHY-provided delay is not doubled by the MAC controller.
> > >=20
> > > The corresponding U-Boot change has been submitted to openbmc/u-boot:
> > > Link: https://lore.kernel.org/all/20260629105202.1417679-1-jackyhuang=
@nvidia.com/
> > >=20
> > > Reviewed-by: Andrew Lunn <[email protected]>
> > > Signed-off-by: Jacky Huang <[email protected]>
> > > ---
> > > v3: reword the &mac0 comment per Andrew Lunn's feedback.
> > >=20
> > > =C2=A0arch/arm/boot/dts/aspeed/Makefile=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 1 +
> > > =C2=A0.../aspeed/aspeed-bmc-nvidia-vr-nvl-bmc.dts=C2=A0=C2=A0 | 901 +=
+++++++++++++++++
> > > =C2=A02 files changed, 902 insertions(+)
> > > =C2=A0create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-nvidia-v=
r-nvl-bmc.dts
> >=20
> > We now have scripts/dtc/dt-check-style, and going forward I'm asking
> > that all new devicetree submissions pass in strict mode.
>=20
> Thanks!
>=20
> >=20
> > Currently:
> >=20
> > =C2=A0=C2=A0 $ ../scripts/dtc/dt-check-style --mode strict ../arch/arm/=
boot/dts/aspeed/aspeed-bmc-nvidia-vr-nvl-bmc.dts 2>&1 | wc -l
> > =C2=A0=C2=A0 152
> >=20
> > Can you please address those?
>=20
> Just a note: --strict might not be ready yet. It reports some false
> positives which need addressing (I have plans for this, but busy with
> other things...), so expectation currently is:
> 1. No warnings from standard mode
> 2. Review and investigate warnings from 'strict' mode, but do not fix
> them automatically without thinking

Understood.

Thanks,

Andrew