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

[Sudeep Holla]

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