[PATCH] firmware: smccc: Pass only the required device probe arguments

[Catalin Marinas]

On Mon, Oct 12, 2026 at 10:39:14AM +0100, Suzuki K Poulose wrote:
> On 11/10/2026 14:25, Aneesh Kumar K.V wrote:
> > Suzuki K Poulose <suzuki.poulose at arm.com> writes:
> > > On 10/10/2026 11:02, Aneesh Kumar K.V (Arm) wrote:
> > > > The device probe passes zeroes for all seven argument registers to
> > > > arm_smccc_1_1_invoke(). On ARM32 Thumb-2, this binds an input to r7 and
> > > > GCC 8.5 reports "r7 cannot be used in asm here".
> > > > 
> > > > The current smccc_devices entries need at most one argument after the
> > > > function ID: TRNG_VERSION has none and RSI_ABI_VERSION takes a requested
> > > > version. Pass zero for that argument and omit the unused arguments,
> > > > avoiding the r7 constraint. Check argument requirements when adding new
> > > > probe functions to smccc_devices.
> > > 
> > > Is it safer to use x1-x3 to 0 as they could be the results that we
> > > get back from SMCCC v1.0 onwards ?
> > 
> > I'm not sure I follow. Passing additional zero arguments only
> > initializes the input registers; it should not affect how return values
> > are handled. arm_smccc_1_1_invoke() already declares x0-x3 as outputs.
> > Since these probe functions require no inputs in x2 or x3 and we only
> > inspect x0 on return, why do we need to initialize them to zero?
> 
> Agree, I meant, passing 0s for x0-x3 future proofs the new calls.
> We know that x0-x3 could get overwritten by these calls, and is
> safe to be zero'd on a call.
> 
> But agree, for the existing users just x1 is enough.

I'd keep it like this for now, it's pretty random anyway. The next time
we need a meaningful argument to pass, we'll probably add an args array
in struct smccc_device_info.

> Either way,
> 
> Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>

Thanks.

-- 
Catalin