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

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

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.

Hi Geert,

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

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

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

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
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
in the drivers themselves guessing on the vendor/subvendor/impl_vers
seems a dangerous abuse...

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

Sorry, I am sure this not a welcomed answer :P ...thoughts ? 

Thanks,
Cristian

[1]: https://xkcd.com/927/