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

[Cristian Marussi]

On Fri, May 08, 2026 at 12:26:19PM +0200, Geert Uytterhoeven wrote:
> Hi Cristian,
> 

Hi,

> On Mon, 27 Apr 2026 at 01:03, Cristian Marussi <cristian.marussi at arm.com> wrote:
> > On Fri, Apr 24, 2026 at 02:08:55PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, 22 Apr 2026 at 20:45, Cristian Marussi <cristian.marussi at arm.com> wrote:
> > > > Also because this should be one of the selling point of the SCMI stack
> > > > in a virtualized environment: you can ship the same kernel drivers with
> > > > the same DT and you know that ID=<N> will always identify the specific
> > > > resource that is needed by your driver without worrying about the fact
> > > > that in reality in the backstage the effectively managed physical resource
> > > > could be different across different platforms, because that does not matter
> > >
> > > This sounds strange to me, do I understand it correctly?
> > > So the ID should (1) be tied to the use-case, and not to the underlying
> > > hardware, and (2) be the same for different platforms?
> > >
> > > For (1): Then we must not put these IDs in DT at all, as DT is supposed
> > >     to describe the hardware (and firmware IDs in DT were IMHO already
> > >     a stretch before).
> > > For (2): How can there be a contiguous list of IDs, as not all platforms
> > >     may have the same underlying hardware?
> >
> > I would NOT say that an SCMI FW must behave like this regarding IDs, but it
> > is a possible SCMI deployed setup that can be useful in virtualized setups
> >
> > I mean, the DT describes the hardware of course BUT when you refer to
> > some of this hardware DT bits from some other subsystem by referencing a
> > phandle, even in the non-SCMI world, you are in fact selecting a specific
> > resource that fit you use case, right ? Can we say this ?
> > I mean you needed that specific clock or regulator that you described
> > previously so as to be able to enable some other piece of HW...
> >
> > Now, the SCMI provides an abstraction on top of this, since you really
> > discover domain IDs of a specific class (clocks/regulators etc) you are
> > in fact describing an HW abstraction that you then refer with the usual
> > phandle...also because there is NOT so much SCMI hardware to describe,
> > given that the HW is handled transparently (opaquely really :P) by the
> > driver on the FW side...
> >
> > ...you basically obtain such domain ID, usable as phandles through dynamic
> > SCMI enumeration so that you can use it all over your DT to make use of such
> > resources...
> >
> > ...on top of this, consider that the SCMI server CAN provide to its agents
> > a per-agent-view of the world, IOW it can (and should) expose to a specific
> > agent ONLY the resources needed by that agent, i.e. it can expose the set
> > of resources 1-N to two distinct agents and that does NOT mean that the
> > underlying physical resource mapped by ID=3 in both agents has to be
> > effectively the same piece of hardware: it could be the case, and this
> > would be useful to exposed and managed properly a shared resource, or
> > it could also be that the same ID=3 could refer to completely distinct
> > pieces of the same class of hardware...(same protocol same class of
> > resource...)
> 
> Exposing only the clocks/reset/power domains the agent can use,
> in a contiguous list of IDS, means that the number space changes,
> depending on which resources are exposed.
> 

Yes, potentially, it depedns on how the HW/FW stack was designed I
suppose...

> Suppose you have a system where you want to assign a specific hardware
> block in the SoC to the realtime CPU core instead of the application
> CPU core running Linux.

Ok, so this is definitely a considerable change.

> That means all resources used by that block must no longer be exposed
> to the Linux agent, and the corresponding IDs must be removed from
> the ID space exposed to Linux.  As the ID space must be sequential
> and contiguous, the IDs must be renumbered, impacting resources that
> are exposed to Linux.  As these IDs are used in the SoC .dtsi, they
> must be changed there, too, However, these IDs have become part of
> the stable DT ABI, and thus cannot be changed.

Well, you have to ship a final DTB blob that is crafted to describe the
actual HW at the end, right ?

I mean, in your example, it seems to me that you have changed considerably
the HW surface by moving a clock (and its related resources) away from the
reach of Linux as a whole, so should not be expected to have an updated
DTB shipped ?

And I am NOT saying to do this by changing the base SoC dtsi, but via build
time overrides and/or runtime overlays so as to derive from that same SoC
base dtsi a properly reviewed final DTB that describes how the HW has actually
changed, becasue beside the renumbering that you mention there will be
also a bunch of HW pieces that were relying on that clock that now will
have to be removed from the DTB if no more usable (or remapped to use a
different, maybe non SCMI resource)

I maybe too naive and not used to very complex DTBs, but why all of the
above cannot be done along the lines of how is done as an example in
JUNO [1], where some initial base dtsi was overriden by virtue of includes
and overrides to properly describe the board at hand (r0/r1/r2), even going
to the extreme, funny enough, to move from the old SCPI to SCMI.

[1]: https://elixir.bootlin.com/linux/v7.0.8/source/arch/arm64/boot/dts/arm/juno-scmi.dts

> 
> This patch series fixes that issue, too, by describing the actual
> hardware in DT, and doing the mapping to exposed SCMI features in the
> kernel, based on which firmware version is running on the SCP.
> 

Which seems to me to go in the opposite direction to what SCMI expects:
but I understand that we have to deal and cope with the existing already
shipped FW, so my concern is not really around enabling this in particular,
is much more the fact that we open the door and normalize this kind of
design even with future, still to be developed, SCMI FWs.

...otherwise...have the spec changed/clarified to allow for such
non-contiguos IDs...

...anyway let's hear Sudeep opinion on this general issue of contiguos
remapped IDs and being able to peek into SCMI version from outside the
SCMI world...

Thanks,
Cristian