Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()

[Cristian Marussi <cristian.marussi@arm.com>]

On Fri, May 15, 2026 at 05:39:45PM +0200, Geert Uytterhoeven wrote:
> Hi Christian,
> 
> On Wed, 22 Apr 2026 at 20:45, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > On Tue, Apr 21, 2026 at 08:11:38PM +0200, Geert Uytterhoeven wrote:
> > > Currently non-SCMI drivers cannot find out what the specific versions of
> > > each SCMI provider implementation on the running system are.
> >
> > Thanks for your patches....this is not a proper full review of the series,
> > BUT this patch catched my eye..
> >
> > Indeed, yes, it is deliberate that the SCMI version information is NOT
> > exposed out of the SCMI world, since being the SCMI an attempt to
> > standardize a common FW interface (as in [1] of course), you should not
> > know what runs inside the black-box, it should be irrelevant...
> >
> > ...indeed the versioning is used inside the SCMI stack to deal properly
> > with different protocol versions implemented by the server OR to apply
> > proper quirks when needed, but all the rest should be standard....
> 
> [...]
> 
> > I watched a bit of the LPC discussions around this (from Marek I think)
> > but sincerely most of those problems had one (not necessarily simple)
> > solution: fix your firmwares AND/OR apply quirks in the meantime...
> 
> So let's forward to the future, where the firmware is fixed, is fully
> compliant with the SCMI spec, and all IDs are stable, so no quirks are
> needed.
> 
> Where do we specify the SCMI IDs to use?  Unless when using the
> remapping driver proposed in this patch series, they must end up in the
> DTB.  Existing upstream users put them either in the SoC-specific .dtsi,
> or in board-specific .dts.
> 
> The SCMI server is supposed to expose to an agent (e.g. Linux) a
> sequential and contiguous list of IDs that represent only resources that
> the agent is allowed to use.
>   - We cannot put the SCMI IDs in the SoC-specific .dtsi, as that
>     describes all hardware in the SoC, which is typically much more than
>     Linux can or even wants to use when running on a specific board.
>   - You would think we could put the SCMI IDs in the board-specific
>     .dts.  However, that would limit actual use cases later, which do
>     not necessarily depend on the board solely.
>       - E.g. when moving control of the CAN-FD controller from Linux to
>         the Realtime OS, the CAN-FD node must be disabled in the DTB (by
>         overriding status to "reserved", or by just deleting the CAN-FD
>         node, both of which can be done by the boot loader). However,
>         with SCMI, the IDs corresponding to CAN-FD resources must be
>         removed from the ID space, causing a full renumbering. Who is
>         supposed to update the IDs in the DTB?

As per my previous email, after such a breaking change I would expect a
new DTB describing the new HW to be needed anyway.

>       - E.g. when partitioning a single Linux system in multiple VMs,
>         and distributing hardware across these VMs, all VMs need
>         different DTBs, each describing a subset of the hardware.  With
>         SCMI, each VM needs different SCMI ID spaces, causing not a
>         simple partitioning of the devices in the DTB, but also a
>         renumbering of all IDs.

Ok now I am lost..why do you need a distinct IDs space for each VM ?

In a virtualized env, I would expect to leverage the SCMI stack to
realize the exact opposite: same set of IDs advertised to each VM (and
so same DTB potentially) by the server which in turn can decide to
assign the same device (and handle the sharing) to some ID or assign
different devices to the same or different IDs on each VM: i.e. you
have a set of virtual_IDs that is what the server exposes to each VM
SCMI agent, and then a bunch of real physical IDs, without any contraint
on their numbering, that the server uses in the backstage to refer to
the real resources and that it properly remaps to each per-VM set of
exposed virtual_IDs during the build and/or boot board configuration
phase....i.e. when the FW adapts and reconfigures to the specific
board that is finally running on.

Thanks,
Cristian