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

[Sudeep Holla]

On Mon, Jun 08, 2026 at 01:49:13PM +0530, Aneesh Kumar K.V wrote:
> Sudeep Holla <sudeep.holla at kernel.org> writes:
> 
> > On Thu, Jun 04, 2026 at 06:56:28PM +0530, Aneesh Kumar K.V wrote:
> >> Sudeep Holla <sudeep.holla at kernel.org> writes:
> >> 
> >> ...
> >> 
> >> > +static const struct smccc_device_info smccc_devices[] __initconst = {
> >> > +       {
> >> > +               .func_id        = ARM_SMCCC_TRNG_VERSION,
> >> > +               .requires_smc   = false,
> >> > +               .min_return     = ARM_SMCCC_TRNG_MIN_VERSION,
> >> > +               .device_name    = "arm-smccc-trng",
> >> > +       },
> >> > +};
> >> > +
> >> > +static bool __init
> >> > +smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
> >> > +{
> >> > +       struct arm_smccc_res res;
> >> > +       unsigned long ret;
> >> > +
> >> > +       if (!IS_ENABLED(CONFIG_ARM64))
> >> > +               return false;
> >> > +
> >> > +       if (smccc_conduit == SMCCC_CONDUIT_NONE)
> >> > +               return false;
> >> > +
> >> > +       if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
> >> > +               return false;
> >> > +
> >> > +       arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
> >> > +       ret = res.a0;
> >> > +
> >> > +       if ((s32)ret < 0)
> >> > +               return false;
> >> > +
> >> > +       return ret >= smccc_dev->min_return;
> >> > +}
> >> > +
> >> >
> >> 
> >> I am not sure we want the check to be as simple as ret < 0. Some
> >> function IDs may return input errors based on the supplied arguments
> >> (for example, RMI_ERROR_INPUT). In those cases, we would likely want
> >> this to be handled via a callback.
> >> 
> >
> > As I mentioned in response to Suzuki, we can defer that to probe of
> > that device. If *_VERSION, succeeds SMCCC core can add that device and
> > leave the rest to the core keeping the core and bus layer simple IMO.
> >
> >> We also want to use conditional compilation for some function IDs.
> >> Given the callback approach and the #ifdefs, I wonder whether what we
> >> currently have is actually simpler and more flexible.”
> >> 
> >
> > 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:
> 

Sounds good to me.

[...]

> We can also move arch/arm64/include/asm/rsi_smc.h to
> include/linux/arm-rsi-smccc.h. There was a suggestion to move these
> firmware interfaces out of architecture-specific code:
> 
> https://lore.kernel.org/all/agsNO9cc7H-b0H8L@willie-the-truck
>

Ah OK, sorry I had missed this.

-- 
Regards,
Sudeep