linux-kernel - Re: [PATCH v3 2/2] dts: aspeed: Add a dts for the nvidia msx4 hpm

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b610d86a2f71bf8289deeaa1c361005146985d2a.camel@codeconstruct.com.au>
Date: Mon, 24 Nov 2025 15:06:56 +1030
From: Andrew Jeffery <andrew@...econstruct.com.au>
To: Marc Olberding <molberding@...dia.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
  Conor Dooley <conor+dt@...nel.org>, Joel Stanley <joel@....id.au>,
 devicetree@...r.kernel.org, 	linux-arm-kernel@...ts.infradead.org,
 linux-aspeed@...ts.ozlabs.org, 	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] dts: aspeed: Add a dts for the nvidia msx4 hpm

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:
> > > +	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?

> 
> > > +	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.
> 
> > 
> > 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