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

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

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   eea3fef32a9cf36abcb5975a5a594e4135a6b026
commit: d8263a131bb05398faa72ac32be54a03e48fa197 [8264/14724] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
config: arm-randconfig-1001-20261007 (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/firmware/smccc/smccc.c: In function 'smccc_devices_init':
>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
    }
    ^
>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here


vim +141 drivers/firmware/smccc/smccc.c

d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  122) 
b83c2d92be719bf Andre Przywara         2021-07-31  123  static int __init smccc_devices_init(void)
b83c2d92be719bf Andre Przywara         2021-07-31  124  {
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  125) 	struct arm_smccc_device *sdev;
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  126) 	const struct smccc_device_info *smccc_dev;
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  127) 
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  128) 	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  129) 		smccc_dev = &smccc_devices[i];
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  130) 
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  131) 		if (!smccc_probe_smccc_device(smccc_dev))
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  132) 			continue;
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  133) 
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  134) 		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  135) 		if (IS_ERR(sdev))
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  136) 			pr_err("%s: could not register device: %pe\n",
d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  137) 			       smccc_dev->device_name, sdev);
b83c2d92be719bf Andre Przywara         2021-07-31  138  	}
b83c2d92be719bf Andre Przywara         2021-07-31  139  
b83c2d92be719bf Andre Przywara         2021-07-31  140  	return 0;
b83c2d92be719bf Andre Przywara         2021-07-31 @141  }

:::::: The code at line 141 was first introduced by commit
:::::: b83c2d92be719bf7b1d24ac02aaa53db3991ea58 firmware: smccc: Register smccc_trng platform device

:::::: TO: Andre Przywara <andre.przywara@arm.com>
:::::: CC: Herbert Xu <herbert@gondor.apana.org.au>

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Aneesh Kumar K.V]

kernel test robot <lkp@intel.com> writes:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head:   eea3fef32a9cf36abcb5975a5a594e4135a6b026
> commit: d8263a131bb05398faa72ac32be54a03e48fa197 [8264/14724] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
> config: arm-randconfig-1001-20261007 (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/config)
> compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
>    drivers/firmware/smccc/smccc.c: In function 'smccc_devices_init':
>>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
>     }
>     ^
>>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
>
>
> vim +141 drivers/firmware/smccc/smccc.c
>
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  122) 
> b83c2d92be719bf Andre Przywara         2021-07-31  123  static int __init smccc_devices_init(void)
> b83c2d92be719bf Andre Przywara         2021-07-31  124  {
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  125) 	struct arm_smccc_device *sdev;
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  126) 	const struct smccc_device_info *smccc_dev;
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  127) 
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  128) 	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  129) 		smccc_dev = &smccc_devices[i];
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  130) 
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  131) 		if (!smccc_probe_smccc_device(smccc_dev))
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  132) 			continue;
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  133) 
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  134) 		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  135) 		if (IS_ERR(sdev))
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  136) 			pr_err("%s: could not register device: %pe\n",
> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  137) 			       smccc_dev->device_name, sdev);
> b83c2d92be719bf Andre Przywara         2021-07-31  138  	}
> b83c2d92be719bf Andre Przywara         2021-07-31  139  
> b83c2d92be719bf Andre Przywara         2021-07-31  140  	return 0;
> b83c2d92be719bf Andre Przywara         2021-07-31 @141  }
>


This is with:

CONFIG_ARM_THUMB=y
CONFIG_ARM_THUMBEE=y

where there are restrictions on the use of r7. IMHO, this needs to be
addressed in the implementation of arm_smccc_1_1_invoke(), rather than
worked around in this patch?

-aneesh

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

[Sudeep Holla]

(+ Marc, Mark)

On Wed, Oct 07, 2026 at 12:28:54PM +0530, Aneesh Kumar K.V wrote:
> kernel test robot <lkp@intel.com> writes:
> 
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > head:   eea3fef32a9cf36abcb5975a5a594e4135a6b026
> > commit: d8263a131bb05398faa72ac32be54a03e48fa197 [8264/14724] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
> > config: arm-randconfig-1001-20261007 (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/config)
> > compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/
> >
> > All errors (new ones prefixed by >>):
> >
> >    drivers/firmware/smccc/smccc.c: In function 'smccc_devices_init':
> >>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
> >     }
> >     ^
> >>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
> >
> >
> > vim +141 drivers/firmware/smccc/smccc.c
> >
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  122) 
> > b83c2d92be719bf Andre Przywara         2021-07-31  123  static int __init smccc_devices_init(void)
> > b83c2d92be719bf Andre Przywara         2021-07-31  124  {
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  125) 	struct arm_smccc_device *sdev;
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  126) 	const struct smccc_device_info *smccc_dev;
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  127) 
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  128) 	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  129) 		smccc_dev = &smccc_devices[i];
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  130) 
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  131) 		if (!smccc_probe_smccc_device(smccc_dev))
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  132) 			continue;
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  133) 
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  134) 		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  135) 		if (IS_ERR(sdev))
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  136) 			pr_err("%s: could not register device: %pe\n",
> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  137) 			       smccc_dev->device_name, sdev);
> > b83c2d92be719bf Andre Przywara         2021-07-31  138  	}
> > b83c2d92be719bf Andre Przywara         2021-07-31  139  
> > b83c2d92be719bf Andre Przywara         2021-07-31  140  	return 0;
> > b83c2d92be719bf Andre Przywara         2021-07-31 @141  }
> >
> 
> 
> This is with:
> 
> CONFIG_ARM_THUMB=y
> CONFIG_ARM_THUMBEE=y
> 
> where there are restrictions on the use of r7. IMHO, this needs to be
> addressed in the implementation of arm_smccc_1_1_invoke(), rather than
> worked around in this patch?
>

We can even drop the extra arguments set 0 as it was original used in
TRNG or just use 4 arguments. That shouldn't impact <FEAT>_VERSION ABIs.

I think there is a precedent here with `SMCCC_ARCH_WORKAROUND_*` calls.
`__arm_smccc_1_1()` is deliberately variadic: it sets up only the input
registers supplied by the caller. Not sure if it is trivial to meddle with
the macro to handle this as workaround.

Regards,
Sudeep

-->8

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);
        ret = res.a0;

        if (ret == SMCCC_RET_NOT_SUPPORTED)

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

[Aneesh Kumar K.V]

Aneesh Kumar K.V <aneesh.kumar@kernel.org> writes:

> kernel test robot <lkp@intel.com> writes:
>
>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> head:   eea3fef32a9cf36abcb5975a5a594e4135a6b026
>> commit: d8263a131bb05398faa72ac32be54a03e48fa197 [8264/14724] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
>> config: arm-randconfig-1001-20261007 (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/config)
>> compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/reproduce)
>>
>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>> the same patch/commit), kindly add following tags
>> | Reported-by: kernel test robot <lkp@intel.com>
>> | Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/
>>
>> All errors (new ones prefixed by >>):
>>
>>    drivers/firmware/smccc/smccc.c: In function 'smccc_devices_init':
>>>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
>>     }
>>     ^
>>>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
>>
>>
>> vim +141 drivers/firmware/smccc/smccc.c
>>
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  122) 
>> b83c2d92be719bf Andre Przywara         2021-07-31  123  static int __init smccc_devices_init(void)
>> b83c2d92be719bf Andre Przywara         2021-07-31  124  {
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  125) 	struct arm_smccc_device *sdev;
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  126) 	const struct smccc_device_info *smccc_dev;
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  127) 
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  128) 	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  129) 		smccc_dev = &smccc_devices[i];
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  130) 
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  131) 		if (!smccc_probe_smccc_device(smccc_dev))
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  132) 			continue;
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  133) 
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  134) 		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  135) 		if (IS_ERR(sdev))
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  136) 			pr_err("%s: could not register device: %pe\n",
>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  137) 			       smccc_dev->device_name, sdev);
>> b83c2d92be719bf Andre Przywara         2021-07-31  138  	}
>> b83c2d92be719bf Andre Przywara         2021-07-31  139  
>> b83c2d92be719bf Andre Przywara         2021-07-31  140  	return 0;
>> b83c2d92be719bf Andre Przywara         2021-07-31 @141  }
>>
>
>
> This is with:
>
> CONFIG_ARM_THUMB=y
> CONFIG_ARM_THUMBEE=y
>
> where there are restrictions on the use of r7. IMHO, this needs to be
> addressed in the implementation of arm_smccc_1_1_invoke(), rather than
> worked around in this patch?
>

Something like this? The -fno-omit-frame-pointer compiler option is
required to reproduce the build error.

firmware: smccc: Avoid inline r7 constraints for Thumb-2 calls

The SMCCC device probe passes eight register arguments to
arm_smccc_1_1_invoke(). With GCC 8.5 and CONFIG_THUMB2_KERNEL=y, the
kernel test robot reports "r7 cannot be used in asm here" while
compiling smccc_devices_init(). The eight-input inline helpers bind
the final argument to r7, which GCC cannot allocate in this function.

Use the existing out-of-line SMC and HVC helpers for eight-input calls
on ARM32 Thumb-2. The helpers load the stack arguments into r4-r7
before entering firmware and save and restore the caller's registers.
Preserve all input arguments and provide a temporary result buffer
when the caller supplies NULL.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/
Assisted-by: LLM
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>

1 file changed, 70 insertions(+), 3 deletions(-)
include/linux/arm-smccc.h | 73 +++++++++++++++++++++++++++++++++++++++++++++--

modified   include/linux/arm-smccc.h
@@ -640,6 +640,39 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
 			*___res = (typeof(*___res)){r0, r1, r2, r3};	\
 	} while (0)
 
+#if defined(CONFIG_ARM) && defined(CONFIG_THUMB2_KERNEL)
+/*
+ * GCC may reserve r7 in Thumb-2 functions. Calls with eight inputs must
+ * therefore use the assembly helpers, which save and restore r7 themselves.
+ */
+#define __arm_smccc_1_1_out_of_line(fn, inst, a0, a1, a2, a3, a4, a5, a6, a7, res) \
+	do {\
+		struct arm_smccc_res __res;\
+		struct arm_smccc_res *__res_ptr = (res);\
+\
+		fn((u32)(a0), a1, a2, a3, a4, a5, a6, a7,\
+		   __res_ptr ? __res_ptr : &__res);\
+	} while (0)
+
+#define __arm_smccc_1_1_inline(fn, inst, ...) \
+	__arm_smccc_1_1(inst, __VA_ARGS__)
+
+#define __arm_smccc_1_1_call_2 __arm_smccc_1_1_inline
+#define __arm_smccc_1_1_call_3 __arm_smccc_1_1_inline
+#define __arm_smccc_1_1_call_4 __arm_smccc_1_1_inline
+#define __arm_smccc_1_1_call_5 __arm_smccc_1_1_inline
+#define __arm_smccc_1_1_call_6 __arm_smccc_1_1_inline
+#define __arm_smccc_1_1_call_7 __arm_smccc_1_1_inline
+#define __arm_smccc_1_1_call_8 __arm_smccc_1_1_inline
+#define __arm_smccc_1_1_call_9 __arm_smccc_1_1_out_of_line
+
+#define __arm_smccc_1_1_call(fn, inst, ...) \
+	CONCATENATE(__arm_smccc_1_1_call_, COUNT_ARGS(__VA_ARGS__))(fn, inst, __VA_ARGS__)
+#else
+#define __arm_smccc_1_1_call(fn, inst, ...) \
+	__arm_smccc_1_1(inst, __VA_ARGS__)
+#endif
+
 /*
  * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call
  *
@@ -654,7 +687,8 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
  * to the SMC instruction. The return values are updated with the content
  * from register 0 to 3 on return from the SMC instruction if not NULL.
  */
-#define arm_smccc_1_1_smc(...)	__arm_smccc_1_1(SMCCC_SMC_INST, __VA_ARGS__)
+#define arm_smccc_1_1_smc(...) \
+	__arm_smccc_1_1_call(arm_smccc_smc, SMCCC_SMC_INST, __VA_ARGS__)
 
 /*
  * arm_smccc_1_1_hvc() - make an SMCCC v1.1 compliant HVC call
@@ -670,14 +704,15 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
  * to the HVC instruction. The return values are updated with the content
  * from register 0 to 3 on return from the HVC instruction if not NULL.
  */
-#define arm_smccc_1_1_hvc(...)	__arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
+#define arm_smccc_1_1_hvc(...) \
+	__arm_smccc_1_1_call(arm_smccc_hvc, SMCCC_HVC_INST, __VA_ARGS__)
 
 /*
  * Like arm_smccc_1_1* but always returns SMCCC_RET_NOT_SUPPORTED.
  * Used when the SMCCC conduit is not defined. The empty asm statement
  * avoids compiler warnings about unused variables.
  */
-#define __fail_smccc_1_1(...)						\
+#define __fail_smccc_1_1_inline(...)					\
 	do {								\
 		CONCATENATE(__declare_arg_,				\
 			    COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__);	\
@@ -689,6 +724,38 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
 			___res->a0 = SMCCC_RET_NOT_SUPPORTED;		\
 	} while (0)
 
+#if defined(CONFIG_ARM) && defined(CONFIG_THUMB2_KERNEL)
+#define __fail_smccc_1_1_no_regs(_a0, _a1, _a2, _a3, _a4, _a5, _a6, _a7, res) \
+	do {\
+		struct arm_smccc_res *__res_ptr = (res);\
+\
+		(void)(_a0);\
+		(void)(_a1);\
+		(void)(_a2);\
+		(void)(_a3);\
+		(void)(_a4);\
+		(void)(_a5);\
+		(void)(_a6);\
+		(void)(_a7);\
+		if (__res_ptr)\
+			__res_ptr->a0 = SMCCC_RET_NOT_SUPPORTED;\
+	} while (0)
+
+#define __fail_smccc_1_1_2 __fail_smccc_1_1_inline
+#define __fail_smccc_1_1_3 __fail_smccc_1_1_inline
+#define __fail_smccc_1_1_4 __fail_smccc_1_1_inline
+#define __fail_smccc_1_1_5 __fail_smccc_1_1_inline
+#define __fail_smccc_1_1_6 __fail_smccc_1_1_inline
+#define __fail_smccc_1_1_7 __fail_smccc_1_1_inline
+#define __fail_smccc_1_1_8 __fail_smccc_1_1_inline
+#define __fail_smccc_1_1_9 __fail_smccc_1_1_no_regs
+
+#define __fail_smccc_1_1(...) \
+	CONCATENATE(__fail_smccc_1_1_, COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__)
+#else
+#define __fail_smccc_1_1(...)	__fail_smccc_1_1_inline(__VA_ARGS__)
+#endif
+
 /*
  * arm_smccc_1_1_invoke() - make an SMCCC v1.1 compliant call
  *

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

[Catalin Marinas]

On Wed, Oct 07, 2026 at 09:44:29AM +0100, Sudeep Holla wrote:
> On Wed, Oct 07, 2026 at 12:28:54PM +0530, Aneesh Kumar K.V wrote:
> > kernel test robot <lkp@intel.com> writes:
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > > head:   eea3fef32a9cf36abcb5975a5a594e4135a6b026
> > > commit: d8263a131bb05398faa72ac32be54a03e48fa197 [8264/14724] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
> > > config: arm-randconfig-1001-20261007 (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/config)
> > > compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/reproduce)
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > >    drivers/firmware/smccc/smccc.c: In function 'smccc_devices_init':
> > >>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
> > >     }
> > >     ^
> > >>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
> > >
> > >
> > > vim +141 drivers/firmware/smccc/smccc.c
> > >
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  122) 
> > > b83c2d92be719bf Andre Przywara         2021-07-31  123  static int __init smccc_devices_init(void)
> > > b83c2d92be719bf Andre Przywara         2021-07-31  124  {
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  125) 	struct arm_smccc_device *sdev;
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  126) 	const struct smccc_device_info *smccc_dev;
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  127) 
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  128) 	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  129) 		smccc_dev = &smccc_devices[i];
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  130) 
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  131) 		if (!smccc_probe_smccc_device(smccc_dev))
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  132) 			continue;
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  133) 
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  134) 		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  135) 		if (IS_ERR(sdev))
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  136) 			pr_err("%s: could not register device: %pe\n",
> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  137) 			       smccc_dev->device_name, sdev);
> > > b83c2d92be719bf Andre Przywara         2021-07-31  138  	}
> > > b83c2d92be719bf Andre Przywara         2021-07-31  139  
> > > b83c2d92be719bf Andre Przywara         2021-07-31  140  	return 0;
> > > b83c2d92be719bf Andre Przywara         2021-07-31 @141  }
> > 
> > This is with:
> > 
> > CONFIG_ARM_THUMB=y
> > CONFIG_ARM_THUMBEE=y
> > 
> > where there are restrictions on the use of r7. IMHO, this needs to be
> > addressed in the implementation of arm_smccc_1_1_invoke(), rather than
> 
> We can even drop the extra arguments set 0 as it was original used in
> TRNG or just use 4 arguments. That shouldn't impact <FEAT>_VERSION ABIs.
> 
> I think there is a precedent here with `SMCCC_ARCH_WORKAROUND_*` calls.
> `__arm_smccc_1_1()` is deliberately variadic: it sets up only the input
> registers supplied by the caller. Not sure if it is trivial to meddle with
> the macro to handle this as workaround.
> 
> Regards,
> Sudeep
> 
> -->8
> 
> 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.

-- 
Catalin

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

[Sudeep Holla]

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:
> > On Wed, Oct 07, 2026 at 12:28:54PM +0530, Aneesh Kumar K.V wrote:
> > > kernel test robot <lkp@intel.com> writes:
> > > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > > > head:   eea3fef32a9cf36abcb5975a5a594e4135a6b026
> > > > commit: d8263a131bb05398faa72ac32be54a03e48fa197 [8264/14724] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
> > > > config: arm-randconfig-1001-20261007 (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/config)
> > > > compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
> > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/reproduce)
> > > >
> > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > > the same patch/commit), kindly add following tags
> > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/
> > > >
> > > > All errors (new ones prefixed by >>):
> > > >
> > > >    drivers/firmware/smccc/smccc.c: In function 'smccc_devices_init':
> > > >>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
> > > >     }
> > > >     ^
> > > >>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
> > > >
> > > >
> > > > vim +141 drivers/firmware/smccc/smccc.c
> > > >
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  122) 
> > > > b83c2d92be719bf Andre Przywara         2021-07-31  123  static int __init smccc_devices_init(void)
> > > > b83c2d92be719bf Andre Przywara         2021-07-31  124  {
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  125) 	struct arm_smccc_device *sdev;
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  126) 	const struct smccc_device_info *smccc_dev;
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  127) 
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  128) 	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  129) 		smccc_dev = &smccc_devices[i];
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  130) 
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  131) 		if (!smccc_probe_smccc_device(smccc_dev))
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  132) 			continue;
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  133) 
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  134) 		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  135) 		if (IS_ERR(sdev))
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  136) 			pr_err("%s: could not register device: %pe\n",
> > > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  137) 			       smccc_dev->device_name, sdev);
> > > > b83c2d92be719bf Andre Przywara         2021-07-31  138  	}
> > > > b83c2d92be719bf Andre Przywara         2021-07-31  139  
> > > > b83c2d92be719bf Andre Przywara         2021-07-31  140  	return 0;
> > > > b83c2d92be719bf Andre Przywara         2021-07-31 @141  }
> > > 
> > > This is with:
> > > 
> > > CONFIG_ARM_THUMB=y
> > > CONFIG_ARM_THUMBEE=y
> > > 
> > > where there are restrictions on the use of r7. IMHO, this needs to be
> > > addressed in the implementation of arm_smccc_1_1_invoke(), rather than
> > 
> > We can even drop the extra arguments set 0 as it was original used in
> > TRNG or just use 4 arguments. That shouldn't impact <FEAT>_VERSION ABIs.
> > 
> > I think there is a precedent here with `SMCCC_ARCH_WORKAROUND_*` calls.
> > `__arm_smccc_1_1()` is deliberately variadic: it sets up only the input
> > registers supplied by the caller. Not sure if it is trivial to meddle with
> > the macro to handle this as workaround.
> > 
> > Regards,
> > Sudeep
> > 
> > -->8
> > 
> > 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.

I don't recall if we discussed this angle much or if I didn't even propose
it 😢.

-- 
Regards,
Sudeep

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

[Aneesh Kumar K.V]

Sudeep Holla <sudeep.holla@kernel.org> writes:

> (+ Marc, Mark)
>
> On Wed, Oct 07, 2026 at 12:28:54PM +0530, Aneesh Kumar K.V wrote:
>> kernel test robot <lkp@intel.com> writes:
>> 
>> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> > head:   eea3fef32a9cf36abcb5975a5a594e4135a6b026
>> > commit: d8263a131bb05398faa72ac32be54a03e48fa197 [8264/14724] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
>> > config: arm-randconfig-1001-20261007 (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/config)
>> > compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
>> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/reproduce)
>> >
>> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
>> > the same patch/commit), kindly add following tags
>> > | Reported-by: kernel test robot <lkp@intel.com>
>> > | Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/
>> >
>> > All errors (new ones prefixed by >>):
>> >
>> >    drivers/firmware/smccc/smccc.c: In function 'smccc_devices_init':
>> >>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
>> >     }
>> >     ^
>> >>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
>> >
>> >
>> > vim +141 drivers/firmware/smccc/smccc.c
>> >
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  122) 
>> > b83c2d92be719bf Andre Przywara         2021-07-31  123  static int __init smccc_devices_init(void)
>> > b83c2d92be719bf Andre Przywara         2021-07-31  124  {
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  125) 	struct arm_smccc_device *sdev;
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  126) 	const struct smccc_device_info *smccc_dev;
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  127) 
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  128) 	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  129) 		smccc_dev = &smccc_devices[i];
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  130) 
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  131) 		if (!smccc_probe_smccc_device(smccc_dev))
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  132) 			continue;
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  133) 
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  134) 		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  135) 		if (IS_ERR(sdev))
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  136) 			pr_err("%s: could not register device: %pe\n",
>> > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  137) 			       smccc_dev->device_name, sdev);
>> > b83c2d92be719bf Andre Przywara         2021-07-31  138  	}
>> > b83c2d92be719bf Andre Przywara         2021-07-31  139  
>> > b83c2d92be719bf Andre Przywara         2021-07-31  140  	return 0;
>> > b83c2d92be719bf Andre Przywara         2021-07-31 @141  }
>> >
>> 
>> 
>> This is with:
>> 
>> CONFIG_ARM_THUMB=y
>> CONFIG_ARM_THUMBEE=y
>> 
>> where there are restrictions on the use of r7. IMHO, this needs to be
>> addressed in the implementation of arm_smccc_1_1_invoke(), rather than
>> worked around in this patch?
>>
>
> We can even drop the extra arguments set 0 as it was original used in
> TRNG or just use 4 arguments. That shouldn't impact <FEAT>_VERSION ABIs.
>
> I think there is a precedent here with `SMCCC_ARCH_WORKAROUND_*` calls.
> `__arm_smccc_1_1()` is deliberately variadic: it sets up only the input
> registers supplied by the caller. Not sure if it is trivial to meddle with
> the macro to handle this as workaround.
>
> Regards,
> Sudeep
>
> -->8
>
> 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);
>         ret = res.a0;
>

However, we used the seven-argument form here because we do not know
which input registers a particular SMCCC function may use.

-aneesh

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

[Aneesh Kumar K.V]

Catalin Marinas <catalin.marinas@arm.com> writes:

> On Wed, Oct 07, 2026 at 09:44:29AM +0100, Sudeep Holla wrote:
>> On Wed, Oct 07, 2026 at 12:28:54PM +0530, Aneesh Kumar K.V wrote:
>> > kernel test robot <lkp@intel.com> writes:
>> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> > > head:   eea3fef32a9cf36abcb5975a5a594e4135a6b026
>> > > commit: d8263a131bb05398faa72ac32be54a03e48fa197 [8264/14724] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
>> > > config: arm-randconfig-1001-20261007 (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/config)
>> > > compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
>> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/reproduce)
>> > >
>> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
>> > > the same patch/commit), kindly add following tags
>> > > | Reported-by: kernel test robot <lkp@intel.com>
>> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/
>> > >
>> > > All errors (new ones prefixed by >>):
>> > >
>> > >    drivers/firmware/smccc/smccc.c: In function 'smccc_devices_init':
>> > >>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
>> > >     }
>> > >     ^
>> > >>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
>> > >
>> > >
>> > > vim +141 drivers/firmware/smccc/smccc.c
>> > >
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  122) 
>> > > b83c2d92be719bf Andre Przywara         2021-07-31  123  static int __init smccc_devices_init(void)
>> > > b83c2d92be719bf Andre Przywara         2021-07-31  124  {
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  125) 	struct arm_smccc_device *sdev;
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  126) 	const struct smccc_device_info *smccc_dev;
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  127) 
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  128) 	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  129) 		smccc_dev = &smccc_devices[i];
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  130) 
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  131) 		if (!smccc_probe_smccc_device(smccc_dev))
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  132) 			continue;
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  133) 
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  134) 		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  135) 		if (IS_ERR(sdev))
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  136) 			pr_err("%s: could not register device: %pe\n",
>> > > d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  137) 			       smccc_dev->device_name, sdev);
>> > > b83c2d92be719bf Andre Przywara         2021-07-31  138  	}
>> > > b83c2d92be719bf Andre Przywara         2021-07-31  139  
>> > > b83c2d92be719bf Andre Przywara         2021-07-31  140  	return 0;
>> > > b83c2d92be719bf Andre Przywara         2021-07-31 @141  }
>> > 
>> > This is with:
>> > 
>> > CONFIG_ARM_THUMB=y
>> > CONFIG_ARM_THUMBEE=y
>> > 
>> > where there are restrictions on the use of r7. IMHO, this needs to be
>> > addressed in the implementation of arm_smccc_1_1_invoke(), rather than
>> 
>> We can even drop the extra arguments set 0 as it was original used in
>> TRNG or just use 4 arguments. That shouldn't impact <FEAT>_VERSION ABIs.
>> 
>> I think there is a precedent here with `SMCCC_ARCH_WORKAROUND_*` calls.
>> `__arm_smccc_1_1()` is deliberately variadic: it sets up only the input
>> registers supplied by the caller. Not sure if it is trivial to meddle with
>> the macro to handle this as workaround.
>> 
>> Regards,
>> Sudeep
>> 
>> -->8
>> 
>> 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.
>

We are only checking whether the result is SMCCC_RET_NOT_SUPPORTED. The
assumption was that the argument register values therefore did not
matter. If a function expects a value within a specific range, it may
return an error for an invalid value, but not SMCCC_RET_NOT_SUPPORTED.

We passed zeroes to avoid exposing stale register contents to components
that are not supposed to read them. In particular, if an SMC is
forwarded to a non-secure host, we do not want that host to see those
register contents. However, this concern does not apply to the two
version-query function IDs used here.

We could therefore use:

	arm_smccc_1_1_invoke(smccc_dev->func_id, &res);

and note that this table must not contain function IDs that are
forwarded to another component. Alternatively, we can retain the
seven-argument form and fix the macro as proposed here?:

https://lore.kernel.org/all/yq5a8q49522f.fsf@kernel.org/

-aneesh

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

[Sudeep Holla]

On Wed, Oct 07, 2026 at 03:09:27PM +0530, Aneesh Kumar K.V wrote:
> Sudeep Holla <sudeep.holla@kernel.org> writes:
> 

[...]

> 
> However, we used the seven-argument form here because we do not know
> which input registers a particular SMCCC function may use.
> 

Agreed, but as Catalin mentioned, it raises question on how generic can
this call be by passing all other arguments as 0s. I did mention some
alternative there.

-- 
Regards,
Sudeep

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

[Aneesh Kumar K.V]

Adding Marc Zyngier and Mark Rutland to the reply. 

Aneesh Kumar K.V <aneesh.kumar@kernel.org> writes:

> Aneesh Kumar K.V <aneesh.kumar@kernel.org> writes:
>
>> kernel test robot <lkp@intel.com> writes:
>>
>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>> head:   eea3fef32a9cf36abcb5975a5a594e4135a6b026
>>> commit: d8263a131bb05398faa72ac32be54a03e48fa197 [8264/14724] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
>>> config: arm-randconfig-1001-20261007 (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/config)
>>> compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
>>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261007/202610070641.B8hxBJcf-lkp@intel.com/reproduce)
>>>
>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>>> the same patch/commit), kindly add following tags
>>> | Reported-by: kernel test robot <lkp@intel.com>
>>> | Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>>    drivers/firmware/smccc/smccc.c: In function 'smccc_devices_init':
>>>>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
>>>     }
>>>     ^
>>>>> drivers/firmware/smccc/smccc.c:141:1: error: r7 cannot be used in asm here
>>>
>>>
>>> vim +141 drivers/firmware/smccc/smccc.c
>>>
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  122) 
>>> b83c2d92be719bf Andre Przywara         2021-07-31  123  static int __init smccc_devices_init(void)
>>> b83c2d92be719bf Andre Przywara         2021-07-31  124  {
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  125) 	struct arm_smccc_device *sdev;
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  126) 	const struct smccc_device_info *smccc_dev;
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  127) 
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  128) 	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  129) 		smccc_dev = &smccc_devices[i];
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  130) 
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  131) 		if (!smccc_probe_smccc_device(smccc_dev))
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  132) 			continue;
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  133) 
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  134) 		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  135) 		if (IS_ERR(sdev))
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  136) 			pr_err("%s: could not register device: %pe\n",
>>> d8263a131bb0539 Aneesh Kumar K.V (Arm  2026-09-23  137) 			       smccc_dev->device_name, sdev);
>>> b83c2d92be719bf Andre Przywara         2021-07-31  138  	}
>>> b83c2d92be719bf Andre Przywara         2021-07-31  139  
>>> b83c2d92be719bf Andre Przywara         2021-07-31  140  	return 0;
>>> b83c2d92be719bf Andre Przywara         2021-07-31 @141  }
>>>
>>
>>
>> This is with:
>>
>> CONFIG_ARM_THUMB=y
>> CONFIG_ARM_THUMBEE=y
>>
>> where there are restrictions on the use of r7. IMHO, this needs to be
>> addressed in the implementation of arm_smccc_1_1_invoke(), rather than
>> worked around in this patch?
>>
>
> Something like this? The -fno-omit-frame-pointer compiler option is
> required to reproduce the build error.
>
> firmware: smccc: Avoid inline r7 constraints for Thumb-2 calls
>
> The SMCCC device probe passes eight register arguments to
> arm_smccc_1_1_invoke(). With GCC 8.5 and CONFIG_THUMB2_KERNEL=y, the
> kernel test robot reports "r7 cannot be used in asm here" while
> compiling smccc_devices_init(). The eight-input inline helpers bind
> the final argument to r7, which GCC cannot allocate in this function.
>
> Use the existing out-of-line SMC and HVC helpers for eight-input calls
> on ARM32 Thumb-2. The helpers load the stack arguments into r4-r7
> before entering firmware and save and restore the caller's registers.
> Preserve all input arguments and provide a temporary result buffer
> when the caller supplies NULL.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202610070641.B8hxBJcf-lkp@intel.com/
> Assisted-by: LLM
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>
> 1 file changed, 70 insertions(+), 3 deletions(-)
> include/linux/arm-smccc.h | 73 +++++++++++++++++++++++++++++++++++++++++++++--
>
> modified   include/linux/arm-smccc.h
> @@ -640,6 +640,39 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
>  			*___res = (typeof(*___res)){r0, r1, r2, r3};	\
>  	} while (0)
>  
> +#if defined(CONFIG_ARM) && defined(CONFIG_THUMB2_KERNEL)
> +/*
> + * GCC may reserve r7 in Thumb-2 functions. Calls with eight inputs must
> + * therefore use the assembly helpers, which save and restore r7 themselves.
> + */
> +#define __arm_smccc_1_1_out_of_line(fn, inst, a0, a1, a2, a3, a4, a5, a6, a7, res) \
> +	do {\
> +		struct arm_smccc_res __res;\
> +		struct arm_smccc_res *__res_ptr = (res);\
> +\
> +		fn((u32)(a0), a1, a2, a3, a4, a5, a6, a7,\
> +		   __res_ptr ? __res_ptr : &__res);\
> +	} while (0)
> +
> +#define __arm_smccc_1_1_inline(fn, inst, ...) \
> +	__arm_smccc_1_1(inst, __VA_ARGS__)
> +
> +#define __arm_smccc_1_1_call_2 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_3 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_4 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_5 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_6 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_7 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_8 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_9 __arm_smccc_1_1_out_of_line
> +
> +#define __arm_smccc_1_1_call(fn, inst, ...) \
> +	CONCATENATE(__arm_smccc_1_1_call_, COUNT_ARGS(__VA_ARGS__))(fn, inst, __VA_ARGS__)
> +#else
> +#define __arm_smccc_1_1_call(fn, inst, ...) \
> +	__arm_smccc_1_1(inst, __VA_ARGS__)
> +#endif
> +
>  /*
>   * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call
>   *
> @@ -654,7 +687,8 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
>   * to the SMC instruction. The return values are updated with the content
>   * from register 0 to 3 on return from the SMC instruction if not NULL.
>   */
> -#define arm_smccc_1_1_smc(...)	__arm_smccc_1_1(SMCCC_SMC_INST, __VA_ARGS__)
> +#define arm_smccc_1_1_smc(...) \
> +	__arm_smccc_1_1_call(arm_smccc_smc, SMCCC_SMC_INST, __VA_ARGS__)
>  
>  /*
>   * arm_smccc_1_1_hvc() - make an SMCCC v1.1 compliant HVC call
> @@ -670,14 +704,15 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
>   * to the HVC instruction. The return values are updated with the content
>   * from register 0 to 3 on return from the HVC instruction if not NULL.
>   */
> -#define arm_smccc_1_1_hvc(...)	__arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
> +#define arm_smccc_1_1_hvc(...) \
> +	__arm_smccc_1_1_call(arm_smccc_hvc, SMCCC_HVC_INST, __VA_ARGS__)
>  
>  /*
>   * Like arm_smccc_1_1* but always returns SMCCC_RET_NOT_SUPPORTED.
>   * Used when the SMCCC conduit is not defined. The empty asm statement
>   * avoids compiler warnings about unused variables.
>   */
> -#define __fail_smccc_1_1(...)						\
> +#define __fail_smccc_1_1_inline(...)					\
>  	do {								\
>  		CONCATENATE(__declare_arg_,				\
>  			    COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__);	\
> @@ -689,6 +724,38 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
>  			___res->a0 = SMCCC_RET_NOT_SUPPORTED;		\
>  	} while (0)
>  
> +#if defined(CONFIG_ARM) && defined(CONFIG_THUMB2_KERNEL)
> +#define __fail_smccc_1_1_no_regs(_a0, _a1, _a2, _a3, _a4, _a5, _a6, _a7, res) \
> +	do {\
> +		struct arm_smccc_res *__res_ptr = (res);\
> +\
> +		(void)(_a0);\
> +		(void)(_a1);\
> +		(void)(_a2);\
> +		(void)(_a3);\
> +		(void)(_a4);\
> +		(void)(_a5);\
> +		(void)(_a6);\
> +		(void)(_a7);\
> +		if (__res_ptr)\
> +			__res_ptr->a0 = SMCCC_RET_NOT_SUPPORTED;\
> +	} while (0)
> +
> +#define __fail_smccc_1_1_2 __fail_smccc_1_1_inline
> +#define __fail_smccc_1_1_3 __fail_smccc_1_1_inline
> +#define __fail_smccc_1_1_4 __fail_smccc_1_1_inline
> +#define __fail_smccc_1_1_5 __fail_smccc_1_1_inline
> +#define __fail_smccc_1_1_6 __fail_smccc_1_1_inline
> +#define __fail_smccc_1_1_7 __fail_smccc_1_1_inline
> +#define __fail_smccc_1_1_8 __fail_smccc_1_1_inline
> +#define __fail_smccc_1_1_9 __fail_smccc_1_1_no_regs
> +
> +#define __fail_smccc_1_1(...) \
> +	CONCATENATE(__fail_smccc_1_1_, COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__)
> +#else
> +#define __fail_smccc_1_1(...)	__fail_smccc_1_1_inline(__VA_ARGS__)
> +#endif
> +
>  /*
>   * arm_smccc_1_1_invoke() - make an SMCCC v1.1 compliant call
>   *

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

[Catalin Marinas]

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

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

[Sudeep Holla]

On Wed, Oct 07, 2026 at 11:19:26AM +0100, Catalin Marinas wrote:
> 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).
> 

No, you are right. My bad, I assumed "Standard Secure Service" is part
of "Arm Architecture Service". I should have looked at the table. So yes,
that can't be used. That could be the reason I didn't make that suggestion
and completely forgot about the ranges. Sorry for the noise.

-- 
Regards,
Sudeep

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

[Jason Gunthorpe]

On Wed, Oct 07, 2026 at 02:18:08PM +0530, Aneesh Kumar K.V wrote:
> @@ -640,6 +640,39 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
>  			*___res = (typeof(*___res)){r0, r1, r2, r3};	\
>  	} while (0)
>  
> +#if defined(CONFIG_ARM) && defined(CONFIG_THUMB2_KERNEL)
> +/*
> + * GCC may reserve r7 in Thumb-2 functions. Calls with eight inputs must
> + * therefore use the assembly helpers, which save and restore r7 themselves.
> + */
> +#define __arm_smccc_1_1_out_of_line(fn, inst, a0, a1, a2, a3, a4, a5, a6, a7, res) \
> +	do {\
> +		struct arm_smccc_res __res;\
> +		struct arm_smccc_res *__res_ptr = (res);\
> +\
> +		fn((u32)(a0), a1, a2, a3, a4, a5, a6, a7,\
> +		   __res_ptr ? __res_ptr : &__res);\
> +	} while (0)
> +
> +#define __arm_smccc_1_1_inline(fn, inst, ...) \
> +	__arm_smccc_1_1(inst, __VA_ARGS__)
> +
> +#define __arm_smccc_1_1_call_2 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_3 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_4 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_5 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_6 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_7 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_8 __arm_smccc_1_1_inline
> +#define __arm_smccc_1_1_call_9 __arm_smccc_1_1_out_of_line
> +
> +#define __arm_smccc_1_1_call(fn, inst, ...) \
> +	CONCATENATE(__arm_smccc_1_1_call_, COUNT_ARGS(__VA_ARGS__))(fn, inst, __VA_ARGS__)
> +#else
> +#define __arm_smccc_1_1_call(fn, inst, ...) \
> +	__arm_smccc_1_1(inst, __VA_ARGS__)
> +#endif

I wonder if this could just be something simpler like

#define __arm_smccc_1_1_call(fn, inst, ...)                       \
	({                                                        \
		if (COUNT_ARGS(__VA_ARGS__) >= 7 &&               \
		    IS_ENABLED(CONFIG_THUMB2_KERNEL))             \
			__arm_smccc_1_1_call_(inst, __VA_ARGS__); \
		else                                              \
			__arm_smccc_1_1(inst, __VA_ARGS__);       \
	})

? (still needs to take care of the NULL res)

Jason

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

[Aneesh Kumar K.V]

Jason Gunthorpe <jgg@nvidia.com> writes:

> On Wed, Oct 07, 2026 at 02:18:08PM +0530, Aneesh Kumar K.V wrote:
>> @@ -640,6 +640,39 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
>>  			*___res = (typeof(*___res)){r0, r1, r2, r3};	\
>>  	} while (0)
>>  
>> +#if defined(CONFIG_ARM) && defined(CONFIG_THUMB2_KERNEL)
>> +/*
>> + * GCC may reserve r7 in Thumb-2 functions. Calls with eight inputs must
>> + * therefore use the assembly helpers, which save and restore r7 themselves.
>> + */
>> +#define __arm_smccc_1_1_out_of_line(fn, inst, a0, a1, a2, a3, a4, a5, a6, a7, res) \
>> +	do {\
>> +		struct arm_smccc_res __res;\
>> +		struct arm_smccc_res *__res_ptr = (res);\
>> +\
>> +		fn((u32)(a0), a1, a2, a3, a4, a5, a6, a7,\
>> +		   __res_ptr ? __res_ptr : &__res);\
>> +	} while (0)
>> +
>> +#define __arm_smccc_1_1_inline(fn, inst, ...) \
>> +	__arm_smccc_1_1(inst, __VA_ARGS__)
>> +
>> +#define __arm_smccc_1_1_call_2 __arm_smccc_1_1_inline
>> +#define __arm_smccc_1_1_call_3 __arm_smccc_1_1_inline
>> +#define __arm_smccc_1_1_call_4 __arm_smccc_1_1_inline
>> +#define __arm_smccc_1_1_call_5 __arm_smccc_1_1_inline
>> +#define __arm_smccc_1_1_call_6 __arm_smccc_1_1_inline
>> +#define __arm_smccc_1_1_call_7 __arm_smccc_1_1_inline
>> +#define __arm_smccc_1_1_call_8 __arm_smccc_1_1_inline
>> +#define __arm_smccc_1_1_call_9 __arm_smccc_1_1_out_of_line
>> +
>> +#define __arm_smccc_1_1_call(fn, inst, ...) \
>> +	CONCATENATE(__arm_smccc_1_1_call_, COUNT_ARGS(__VA_ARGS__))(fn, inst, __VA_ARGS__)
>> +#else
>> +#define __arm_smccc_1_1_call(fn, inst, ...) \
>> +	__arm_smccc_1_1(inst, __VA_ARGS__)
>> +#endif
>
> I wonder if this could just be something simpler like
>
> #define __arm_smccc_1_1_call(fn, inst, ...)                       \
> 	({                                                        \
> 		if (COUNT_ARGS(__VA_ARGS__) >= 7 &&               \
> 		    IS_ENABLED(CONFIG_THUMB2_KERNEL))             \
> 			__arm_smccc_1_1_call_(inst, __VA_ARGS__); \
> 		else                                              \
> 			__arm_smccc_1_1(inst, __VA_ARGS__);       \
> 	})
>
> ? (still needs to take care of the NULL res)
>

Sure with the change 
	__arm_smccc_1_1_call_(fn, __VA_ARGS__); \

But, as Catalin suggested, we can keep this simpler for this merge and
do the cleanup later.

-aneesh