On Thu, 2025-11-13 at 22:26 -0800, Marc Olberding wrote:

On Fri, Nov 14, 2025 at 02:46:19PM +1030, Andrew Jeffery wrote:

quoted

quoted

+	model = "AST2600 MSX4 Kernel";

I find this to be a curious model name :)

Are there no other reasonable names?

For better or worse, this is the most accurate name, and matches the hpm hardware itself.

hpm?

We may need multi-hpm support for the resulting firmware at some point, so matching
the hpm to the device tree seemed like the simplest thing to do. If this doesn't
match the way the kernel deals with this sort of thing, please let me know the best path forward.

I guess to clarify my concern: what does "Kernel" refer to here?

The devicetree describes the hardware, so references to things such as
"driver" and "kernel" tend to be a little suspicious.

For reference, here's a sample of other model names that have been
used:

   > git grep model arch/arm/boot/dts/aspeed/ | shuf | head
   arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts: model = "Facebook Harma";
   arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-e3c256d4i.dts:       model = "ASRock E3C256D4I BMC";
   arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minipack.dts:      model = "Facebook Minipack 100 BMC";
   arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts:  model = "Facebook Santabarbara BMC";
   arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-elbert.dts:        model = "Facebook Elbert BMC";
   arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts:    model = "Facebook Greatlakes BMC";
   arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-fuji.dts:       model = "Fuji";
   arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-cmm.dts:   model = "Facebook Backpack CMM BMC";
   arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-balcones.dts:   model = "Balcones";
   arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-rx20.dts:    model = "YADRO VEGMAN Rx20 BMC";

These don't tend to reference either the SoC or the kernel, rather the
platform that the SoC sits in. "MSX4" might be enough?

quoted

quoted

+	compatible = "nvidia,msx4-bmc", "aspeed,ast2600";
+
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart2;
+		serial2 = &uart3;
+		serial3 = &uart4;
+		serial4 = &uart5;

Just checking whether you're actually using all of these? I guess the
uart nodes further down suggest so?

These UARTs are wired up on this platform. Userspace may not use them today,
but we want to enable doing so without needing further device tree updates, in
case they are needed for debug where a BMC firmware flash would be unpalatable.

quoted

Seems curious to enable all of these I2C controllers yet have no
devices under them? Can you elaborate?

Andrew

Unfortunately, the devices that we need over i2c are not
guaranteed to be available at BMC boot, and are probed in userspace through
the new_device sysfs node from the i2c subsystem. The BMC doesn't
have direct control over when these devices are accessible,
they are available after the host has completed POST.

As far as I can tell, there isn't a great way to defer probe for devices
that the BMC doesn't have immediate control over whether its accessible.
Regulators seem like a match, but it seems to assume that you can directly
turn on the power domain that the device is tied to, which isn't the case here
for various reasons.

Please let me know if I'm ignorant of a way to deal with this issue.

No dramas, however, I'd appreciate a comment in the devicetree along
these lines.

Andrew