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

On Fri, Sep 04, 2026 at 10:53:53AM -0300, Jason Gunthorpe wrote:

On Fri, Sep 04, 2026 at 11:02:56AM +0100, Sudeep Holla wrote:

quoted

quoted

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)

Ah got it. I agree with you on their pattern of breaking compatibility
but things are improving, I won't say we are there yet.

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

Ah that is possible, yes I can't disagree.

But I must say it is improving as the firmware teams implementing newer
versions run the existing kernel and spot the issues quickly if anything
is incompatible if the spec hadn't broken it intentionally.

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.

Completely understood.

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.

Really, that's news to me.

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.

Yes agreed. The only argument I had is for the existing users whom we are
fitting into the SMCCC bus like TRNG. But we need some agreement on the
spec consistency if we need to do anything more smart in the core SMCCC
bus code.

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.

But then we will have to wait for that discovery SMCCC ABI first and that
mean how will it work on existing deployed systems ? But I like the idea.

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.

I don't know if I got the details right but I get the overall idea here.

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.

Indeed, I prefer this and get mad if new features are added without
feature bits. Version for me is just for rough indication that ideally
these features must be 0 on a version X but it shouldn't matter for
the software that purely relies on feature bits. So a big yes for that
idea and I think some specs and in some form are doing it. I can't
recall specific but I have seen it. We just need push only for that
in future specs.

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

Completely agreed!

-- 
Regards,
Sudeep