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

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

On Fri, Apr 24, 2026 at 02:08:55PM +0200, Geert Uytterhoeven wrote:
> Hi Cristian,

Hi Geert,

> 
> 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....
> >
> > ...you should NOT really behave differently based on the underneath
> > protocol or firmare implementation version...it is the SCMI stack that
> > should behave properly, transparently...
> 
> Oh well...
> 
> > Having said that...I understand that at least it could be useful to be able
> > to query the SCMI stack to know, even from non-SCMI drivers, WHICH quirks
> > have been applied/activated at run time...but anything more than that it
> 
> I see no need for that, but we can discover which quirks have been
> applied from the kernel log ;-)

Ok so I may have misunderstood...it seemed to me, glancing through the
series that you wanted sort of reconfigure other non-SCMI drivers based
on the SCMI FW version assuming that some quirks were applied BUT also
that some sort of corrective workaround was needed additionally...so
what I was saying was that: is not more straightforward to be possibly
able to check if a quirk has been applied instead of querying the
version from outside ?

> 
> > seems to me dangerous and prone to a number of abuses of the SCMI stack
> > itself...
> >
> > (Also...exposing the versions itself means also tracking that bit of info
> > in more than one place: the quirk framework and your drivers.)
> 
> I'll see if I can get everything handled as quirks instead...
> 
> > > However, different versions may use different ABIs (e.g. different clock
> > > IDs), or behave different, requiring remapping or workarounds in other
> > > drivers.
> >
> > ...abuse like this indeed :P ... the SCMI server is supposed to be that
> > one entity remapping the IDs in the background if the same IDs happen to
> > be representing different physical resources across a number of distinct
> > platforms all supported by the same firmware blob...so as to present
> > a consistent set of contiguos IDs...
> 
> In our case it is just a single platform, with different ID number
> spaces for different firmware versions.

Yes understood.

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

In fact the SCMI server provides an abstraction, sometime a mere illusion
to the agents...

So in a virtualized ennvironment you could expose the same ID to a pair
of distinct agents on distinct VMs, so that you can use the same driver
and same DT despite the fact that maybe the underlying resources are
distinct pieces of hardware ...

...OR on the other side you could decide to share the same resource with
different agents (say a clock) and take care, as a server, of armonizing
conflicting requests from different agents (e.g. by refcounting enable/disable
across all agents), WITHOUT necessarily need to expose that same resource
with the same ID to both agents...

...and you can easily draw a parallel from this virtualization dynamic
scenario to a more static usecase where you have a FW shipped on
multiple boards and so capable of serving, in fact, multiple distinct
agents, but this time, just NOT all together like the VM, but one at time
depending on which board configuration is booted...

....all of this madness of course has a chance to work ONLY if the SCMI
server takes care to remap such resources properly at build-time or
run-time as a contiguos set of IDs, based on the expected agents that
it has to serve

I am, of course, disillusioned enough NOT to believe that many FW were
shipped around trying to fit this ideal SCMI deployment scenario BUT at
least we try, kernel side, NOT to ease these kind of design that goes
pretty much against the SCMI ideas of a system (and the spec to some
extent if you punch holes in the IDs sets), and even more we try NOT
to legalize/normalize out-of-spec FW behaviours by fixing the driver,
where required, and deploying needed quirks to let existing boards survive
(..and that becomes quickly much more a pain in the ass for us then for the
FW guys :P)
 
> > if the SCMI platform server had properly remapped (at build time/run-time ?)
> > the resources to your expected ID...alternatively of course you can ship
> > with different DTs to describe different hardware...BUT remmapping stuff
> 
> That is a different issue: as SCMI covers the full platform, not just
> the SoC, the IDs can be board-specific, and thus should be specified
> in the board .dts, not in the SoC .dtsi?
> Then the SoC .dtsi should describe the hardware, and we end up with
> things like arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts?
> 
> > in the drivers themselves guessing on the vendor/subvendor/impl_vers
> > seems a dangerous abuse...
> 
> There is no guessing.
> 
> > 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...
> 
> Unfortunately (at this point) we have to work with the firmware that exists.
> 
> From that LPC discussion, we learned that we are actually the lucky
> guys: some other vendors tend to change the IDs and/or behavior without
> bumping the version, so Linux cannot even act upon that...
> 

Oh I know that :P ... the whole SCMI quirk framework has been introduced
to cope with FW issue from one vendor that afterwards fixed their FW
issue BUT did NOT take care to update properly their FW versions upon
each release...so their quirks will be like diamonds, forever !
... no matter how many fixed-FW they will deploy :P

Thanks,
Cristian