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

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:

quoted

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

quoted

quoted

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.

quoted

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