Re: [PATCH v9 1/7] firmware: smccc: Add an Arm SMCCC bus

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Sep 04, 2026 at 11:02:56AM +0100, Sudeep Holla wrote:
> > It means you can never publish a version 2 that is ABI breaking
> > because linux doesn't check for that. Was that ARM's intention with
> > the version API? It's basically a completely pointless check that
> > doesn't effectively do anything.
> 
> I didn't get that. The example above checks for minimum TRNG version,
> so it won't break in any way for v2. What am I missing ?

If ARM sticks to what they have done in other specs, a V2 could define
ABI that is not compatible with V1 at all. (semantic versioning and all)

So the kernel check above will happily pass a v2 interface and then
send garbage into the incompatible ABI.

The ecosystem couldn't accept this. An ABI breaking V2 can never
exist, so the versioning is much less useful that a normal semver
scheme.

If it was MAJOR(version) == 1 then it might make a little more sense.

I'm saying that broadly none of this version stuff seems to be doing
much useful work. Even the more complicated RSI lower/uppper stuff was
not good enough and they are going to follow a new scheme.

I think the bus is a nice idea! If you keep going down that logical
path the next stop is to have a SMCCC that discovers the FW ABIs
available. That would be a good moment to take a pause and try to set
a versioning system standard that actually works consistently for the
entire ecosystem.

IMHO to lean into the bus design I would have a discovery SMCCC that
returns a list of supported ABIs, something like (spec, spec version,
ABI, FID, feature supported bitmap).  There could be overlaps if the
FW supports several ABI incompatible versions, like RSI v1 and RSI v2.

Then you do a driver search and the strongest match sees the bus code
issue a "set SMCCC" that says 'I picked index #3 behave like that
please' and then the actual SMCC driver would use a features scheme to
further fine tune things.

Instead of versions you have ABI's and feature bits describing what is
supported. This is far closer to how the HW interfaces ARM designs
tend to work, and is much more aligned to how I understand RMM is
going.

It could be consistent and layer on top of what you have now without
ABI breaking anything.

Regards,
Jason