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

[Sudeep Holla]

On Thu, Sep 03, 2026 at 03:21:52PM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 03, 2026 at 05:18:16PM +0100, Sudeep Holla wrote:
> 
> > Oh yes, we need this whatever you term as "duplication". I would argue
> > against terming it as duplications as if you look at the various SMCCC
> > based specification, we have zero consistency in how the VERSION command
> > is expected to work.
> 
> Okay, then that pretty much settles it. Nothing to do
> 
> > > Missing a check means FW upgrades might become Linux breaking. 
> > 
> > Are you referring to the SMCCC bus code or RSI in particular above. I don't
> > see any issue with SMCCC bus code check as that is the least we can do and
> > must not change with future versions of the firmware as well.
> 
> Just in general, SMCCC drivers have to do something smart with the
> version.
> 
> Like, is this OK:
> 
> #define ARM_SMCCC_TRNG_MIN_VERSION	0x10000UL
> 
> static inline bool smccc_probe_trng(void)
> {
> 	struct arm_smccc_res res;
> 
> 	arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_VERSION, &res);
> 	if ((s32)res.a0 < 0)
> 		return false;
> 
> 	return res.a0 >= ARM_SMCCC_TRNG_MIN_VERSION;
> }
> 
> ?
> 


So it will be specific to each FID range, then what is smart about
generic SMCCC logic then ?

We already have
	if (ret != SMCCC_RET_NOT_SUPPORTED)
		arm_smccc_device_register(..)

Not sure what else can be done.

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

> 
> My broader, more general point is that if SMCC is being made into a
> discoverable bus, that's great, but it would be even better if ARM
> could find a way to progmatically enumerate all the ABIs present on
> the SMCC interface to populate the bus. That would necessarily include
> some consistent treatment of versioning for consistent
> interoperability.

Sure, it can be tried for future SMCCC based specs. We can't ignore the
inconsistency that exists in the currently used SMCCC based specs. So it
can't be ideal as you prefer I am afraid.

> 
> > If lower is also set at v3.0, then I would argue it is firmware upgrade
> > issue expecting old kernel with old RSI version supported to work. If
> > that returns v2.0, the driver must work IIUC. Aneesh, hopefully I got this
> > right ?
> 
> There was many long conversations about this and I think the
> conclusion was RSI will broadly not use versions for any kind of ABI
> control. It is too coarse to really work in the real world and we must
> have strong forward/backwards interoperability inside VMs forever.
> 

OK, I wasn't ware of that.

-- 
Regards,
Sudeep