From: Marc Olberding <molberding@nvidia.com>
To: Andrew Jeffery <andrew@codeconstruct.com.au>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Joel Stanley <joel@jms.id.au>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] dts: aspeed: Add a dts for the nvidia msx4 hpm
Date: Thu, 13 Nov 2025 22:26:48 -0800 [thread overview]
Message-ID: <aRbLqH8pLWCQryhu@molberding.nvidia.com> (raw)
In-Reply-To: <a030d7a2e2d36064bd86fe2af1ec6e4baabd9946.camel@codeconstruct.com.au>
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
next prev parent reply other threads:[~2025-11-14 6:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-08 22:24 [PATCH v3 0/2] Add device tree for Nvidia BMC msx4 cx8 switchboard Marc Olberding
2025-11-08 22:24 ` [PATCH v3 1/2] dt-bindings: arm: aspeed: Add Nvidia msx4 board Marc Olberding
2025-11-08 22:24 ` [PATCH v3 2/2] dts: aspeed: Add a dts for the nvidia msx4 hpm Marc Olberding
2025-11-14 4:16 ` Andrew Jeffery
2025-11-14 6:26 ` Marc Olberding [this message]
2025-11-10 14:34 ` [PATCH v3 0/2] Add device tree for Nvidia BMC msx4 cx8 switchboard Rob Herring (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aRbLqH8pLWCQryhu@molberding.nvidia.com \
--to=molberding@nvidia.com \
--cc=andrew@codeconstruct.com.au \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=joel@jms.id.au \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).