Re: [linux-next:master 8264/14724] drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Oct 07, 2026 at 10:18:16AM +0100, Sudeep Holla wrote:
> On Wed, Oct 07, 2026 at 10:10:42AM +0100, Catalin Marinas wrote:
> > On Wed, Oct 07, 2026 at 09:44:29AM +0100, Sudeep Holla wrote:
> > > diff --git i/drivers/firmware/smccc/smccc.c w/drivers/firmware/smccc/smccc.c
> > > index afc2e4d602ba..dfbd04c8eeac 100644
> > > --- i/drivers/firmware/smccc/smccc.c
> > > +++ w/drivers/firmware/smccc/smccc.c
> > > @@ -116,8 +116,7 @@ static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smcc
> > >         if (IS_ENABLED(CONFIG_ARM) && ARM_SMCCC_IS_64(smccc_dev->func_id))
> > >                 return false;
> > > 
> > > -       arm_smccc_1_1_invoke(smccc_dev->func_id,
> > > -                            0, 0, 0, 0, 0, 0, 0, &res);
> > > +       arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
> > 
> > I think that's going in the right direction and works for TRNG. However,
> > the RSI_ABI_VERSION func_id requires another argument (I think requested
> > interface revision). We could pass (func_id, 0, &res) but I wonder
> > whether this probe function is generic enough to always assume all
> > arguments are 0.
> 
> Agreed, one other thought I had initially was to see if we can simply use
> SMCCC_ARCH_FEATURES(FID) but the spec states
> "Function ID of an Arm Architecture Service Function"
> which could soon become restrictive but IIUC it is not as per the uses
> today in this driver. We could move to that as it is purely SMCCC spec
> and doesn't rely on other SMCCC based specs.

The spec I have around (DEN0028 1.6 G) limits arch_func_id to:

- Arm Architecture Service range:
  0x80000000-0x8000FFFF and 0xC0000000-0xC000FFFF

- Standard Hypervisor Service range:
  0x85000000-0x8500FFFF and 0xC5000000-0xC500FFFF

Any arch_func_id values outside of these ranges are invalid. Both
TRNG_VERSION (0x84000050) and RSI_ABI_VERSION (0xC4000190) are Standard
Secure Service calls, so outside those ranges. So, if I got this
correctly, it wouldn't work in this case (or I need a newer spec).

-- 
Catalin