On 16/02/2026 08:47, Bertrand Marquis wrote:
> The SMCCC v1.1 inline helper currently forces a1-a4 into
> unsigned long and uses in/out constraints for r0-r3. In
> contrast, a5-a7 are passed with their original types via
> read-only constraints. On arm64 this means a 32-bit signed
> value in a1-a4 is converted to a 64-bit unsigned value, while
> the same value in a5-a7 keeps its signed 32-bit form. For
> example, a negative int in a2 is widened to unsigned long, but
> a negative int in a5 is passed as a 32-bit signed value, so the
> SMC sees different encodings depending on argument position.
>
> Switch the helper to use typed input registers arg0-arg7
> derived from the call arguments (keeping a0 cast to u32) and
> separate output registers r0-r3. This preserves argument types
> consistently across all positions. Argument evaluation order
> is unchanged, so we do not reintroduce the issue fixed in
> "e00dc325bd9e" ("xen/arm: smccc-1.1: Handle function result as
> parameters").
>
> This also aligns Xen's SMCCC parameter handling with Linux's type-
> preserving behavior (same externally visible argument handling,
> independent implementation) to avoid surprising differences
> between a1-a4 and a5-a7.
>
> Current callers (PSCI, SCMI, platform SMC pass-through, OP-TEE,
> and exynos5) pass unsigned values; exynos5 passes an int CPU id
> which should always be > 0.
>
> Signed-off-by: Bertrand Marquis <[email protected]>
Reviewed-by: Michal Orzel <[email protected]>
~Michal
