Re: [PATCH u-boot v2] ARM: dts: aspeed: Add dts for ASUS Kommando IPMI card

On Mon, 2026-05-18 at 08:50 -0500, Anirudh Srinivasan wrote:
> Hi Andrew,
> 
> On Mon, May 18, 2026 at 7:59 AM Andrew Jeffery
> <[email protected]> wrote:
> > 
> > Hi Anirudh,
> > 
> > Sorry for the delay :(
> > 
> > On Sat, 2026-03-28 at 14:14 -0500, Anirudh Srinivasan wrote:
> > > Add dts for Asus Kommando IPMI card, an ast2600 based pcie bmc card.
> > > 
> > > This version of the DTS doesn't support networking due to u-boot inserting
> > > mac delays (when it isn't really needed) and needing to misconfigure the
> > > phy-mode in linux due to it. See discussion here [1] for more details.
> > > 
> > > Networking can be enabled in this manner currently.
> > > 
> > > aliases {
> > >         eth0 = &mac2;
> > > };
> > > 
> > > &mac2 {
> > >       status = "okay";
> > >       phy-mode = "rgmii-id";
> > >       phy-handle = <&ethphy2>;
> > >       pinctrl-names = "default";
> > >       pinctrl-0 = <&pinctrl_rgmii3_default>;
> > > };
> > > 
> > > &mdio {
> > >        status = "okay";
> > >        pinctrl-names = "default";
> > >        pinctrl-0 = <&pinctrl_mdio3_default>;
> > >        #address-cells = <1>;
> > >        #size-cells = <0>;
> > > 
> > >        ethphy2: ethernet-phy@2 {
> > >                reg = <0>;
> > >        };
> > > };
> > > 
> > > &scu {
> > >        mac2-clk-delay = <0 0
> > >                          0 0
> > >                          0 0>;
> > > };
> > 
> > So something I didn't appreciate in our previous discussion was that
> > this was a property on the SCU node (I should have looked then).
> > Checking the implementation, it seems to me like this is the same as
> > not specifying the property. That corroborates Ender's efforts here:
> > 
> > https://lore.kernel.org/all/[email protected]/
> > 
> > I think we just drop the property and add in the mac nodes, and remove
> > this note from the commit message?
> > 
> > Possibly some confusion comes from the EVB DTS specifying the property,
> > and everyone just copied it, then wondered why it was all broken.
> 
> I think that the u-boot implementation [1] uses a default value for
> the clk delay if it doesn't find a clk-delay node in the DT. My
> testing also seemed to suggest this, i.e if I dropped the clk-delay
> node node, networking wasn't working. We need a zero clk delay, and
> the default isn't zero.
> 
> Am I correct? I can try testing again when I get some time later on in the week.

Heh, so I did look, but must've glazed over the defaults set at the top
there. I checked the default register value in the datasheet which
claims it is zero, but clearly that was not enough.

So I think what I was hoping to avoid was adding to the devicetrees
properties that are not defined in bindings, but that ship has sailed
for the u-boot fork. I'll drop that line of thought for now.

Looking at the upstream kernel devicetrees, only aspeed-ast2600-evb.dts
specifies `phy-mode = "rgmii-rxid";` (thanks to Andrew Lunn's review
efforts). All MAC nodes set phy-mode where they don't otherwise specify
use-ncsi (which is RMII and not RGMII, and so we can ignore them for
the purpose of this problem).

Inspecting the output of the following in openbmc/u-boot
openbmc/v2019.04-aspeed-openbmc:

   git grep -A 10 -e '^[&]mac.' -e 'mac.-clk-delay' arch/arm/dts/ast2600*

the boards below enable MACs for RGMII but do not set the `mac.-clk-
delay` properties in the SCU node:

- ast2600-fpga.dts
- ast2600-msx4-bmc-nvidia.dts
- ast2600-slt.dts

As such, they rely on the default values you pointed out in the driver.

Perhaps we could add the mac.-clk-delay properties with the default
values currently used by the driver to the SCU devicetree node for
those boards. From there, we can rework clk_ast2600 so that the default
value is no delay from the SCU, and we rely on the devicetrees to
specify what delay, if any, is required, where necessary.

From there, no new u-boot ast2600 devicetrees should require the mac.-
clk-delay properties, and on the MAC nodes we can set `phy-mode =
"rgmii-id";` as appropriate.

I've added Marc to the thread for the MSX4 side of things.

> 
> I looked through Ender's efforts and it seems surprising that it works
> for their board. Maybe the board design is different in some manner
> there?

Yes, that is surprising. I've added Ender to this thread.

Andrew