Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device

[Sudeep Holla <sudeep.holla@kernel.org>]

On Mon, Jun 08, 2026 at 04:56:29PM +0530, Aneesh Kumar K.V wrote:
> Suzuki K Poulose <suzuki.poulose@arm.com> writes:
> 
> > On 08/06/2026 09:19, Aneesh Kumar K.V wrote:
> >> Sudeep Holla <sudeep.holla@kernel.org> writes:
> >> 
> >>> On Thu, Jun 04, 2026 at 06:56:28PM +0530, Aneesh Kumar K.V wrote:
> >>>> Sudeep Holla <sudeep.holla@kernel.org> writes:
> >>>>
> >>>> ...
> 
> ...
> 
> >>> I was trying to avoid conditional compilation altogether and hence the
> >>> reason for keeping it as simple as possible. Also IS_ENABLED(CONFIG_ARM64)
> >>> in above snippet must come as some condition to this generic probe.
> >>>
> >>> Adding any more logic or callback defeats the bus idea here if we need
> >>> to rely/depend on multiple conditional compilation or callbacks IMO.
> >>>
> >>> Let's find see if it can work with what we are adding now and may add in
> >>> near future and then decide.
> >>>
> >> 
> >> If we move all the conditional checks to the driver probe path, then I
> >> think this can work. Something like the below:
> >> 
> >> struct smccc_device_info {
> >> 	u32 func_id;
> >> 	bool requires_smc;
> >> 	const char *device_name;
> >> };
> >> 
> >> static const struct smccc_device_info smccc_devices[] __initconst = {
> >> 	{
> >> 		.func_id        = ARM_SMCCC_TRNG_VERSION,
> >> 		.requires_smc   = false,
> >> 		.device_name    = "arm-smccc-trng",
> >> 	},
> >> 
> >> 	{
> >> 		.func_id        = RSI_ABI_VERSION,
> >
> > Don't we need parameters passed to this (Requested Interface version for 
> > e.g.) ? See more below.
> >
> 
> The idea is that we only check whether the function ID is supported. All
> other conditional logic should be handled in the driver probe path, as
> demonstrated by the changes in drivers/char/hw_random/arm_smccc_trng.c.
> 

+1. Yes, we just want to know whether the firmware is aware of that feature
before creating the `smccc_device` for it. The device probe can then perform a
more thorough, feature-specific check to determine whether the device/feature
is usable.

That is the main idea behind the approach I suggested. Please let me know if
you still see any issues or think this may not work.

-- 
Regards,
Sudeep