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: <aRbLqH8pLWCQryhu@molberding.nvidia.com>
Date: Thu, 13 Nov 2025 22:26:48 -0800
From: Marc Olberding <molberding@...dia.com>
To: Andrew Jeffery <andrew@...econstruct.com.au>
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 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.
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.

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

Thanks for the Review,
Marc