Message-ID: <cc8000c0-e457-4bfc-94de-aeeddacab23b@os.amperecomputing.com>
Date: Wed, 3 Sep 2025 17:38:44 -0400
From: Paul Benoit <paul@...amperecomputing.com>
To: Sudeep Holla <sudeep.holla@....com>,
 Andre Przywara <andre.przywara@....com>
Cc: Mark Rutland <mark.rutland@....com>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] firmware: smccc: Fix Arm SMCCC SOC_ID name call

On 9/3/2025 10:49 AM, Sudeep Holla wrote:
> On Wed, Sep 03, 2025 at 03:23:58PM +0100, Sudeep Holla wrote:
>> On Tue, Sep 02, 2025 at 06:20:53PM +0100, Andre Przywara wrote:
>>> Commit 5f9c23abc477 ("firmware: smccc: Support optional Arm SMCCC SOC_ID
>>> name") introduced the SOC_ID name string call, which reports a human
>>> readable string describing the SoC, as returned by firmware.
>>> The SMCCC spec v1.6 describes this feature as AArch64 only, since we rely
>>> on 8 characters to be transmitted per register. Consequently the SMCCC
>>> call must use the AArch64 calling convention, which requires bit 30 of
>>> the FID to be set. The spec is a bit confusing here, since it mentions
>>> that in the parameter description ("2: SoC name (optionally implemented for
>>> SMC64 calls, ..."), but still prints the FID explicitly as 0x80000002.
>>> But as this FID is using the SMC32 calling convention (correct for the
>>> other two calls), it will not match what mainline TF-A is expecting, so
>>> any call would return NOT_SUPPORTED.
>>>
>>
>> Good catch and I must admit I completely missed it inspite of discussing
>> 32b vs 64b FID around the same time this was introduced.
>>
>>> Add a 64-bit version of the ARCH_SOC_ID FID macro, and use that for the
>>> SoC name version of the call.
>>>
>>> Fixes: 5f9c23abc477 ("firmware: smccc: Support optional Arm SMCCC SOC_ID name")
>>> Signed-off-by: Andre Przywara <andre.przywara@....com>
>>> ---
>>> Hi,
>>>
>>> as somewhat expected, this now fails on an Ampere machine, which
>>> reported a string in /sys/devices/soc0/machine before, but is now missing
>>> this file.
>>> Any idea what's the best way to handle this? Let the code try the 32-bit
>>> FID, when the 64-bit one fails? Or handle this as some kind of erratum?
>>>
>>
>> Not sure about it yet. Erratum seems good option so that we can avoid
>> others getting it wrong too as they might just run the kernel and be happy
>> if the machine sysfs shows up as we decided to do fallback to 32b FID.
>>
>> I will start a discussion to get the spec updated and pushed out and see
>> how that goes.
>>
>> The change itself looks good and happy to get it merged once we know
>> what is the best approach(erratum vs fallback).
>>
> 
> Looking at the SMCCC spec(DEN0028 v1.6 G Edition) ->
> Section 7.4.6 Implementation responsibilities
> 
> If implemented, the firmware:
> ...
> • must not implement SoC_ID_type == 2 for SMC32.
> • can optionally implement SoC_ID_type == 2 for SMC64 (Function ID 0xC000_0002),
> ...
> 
> So Ampere is not spec conformant here and hence I prefer to handle it as
> erratum. Hopefully we can use SOC_ID version and revision to keep the scope
> of erratum confined to smallest set of platforms.
> 
> Paul,
> 
> Thoughts ?
>

Am I correctly understanding that, if the SMC64 SOC_ID Name call fails,
rather than an unconditional fallback to the SMC32 call, the SMC32
fallback would only be occurring under the proposed erratum?

I brought this issue up at a weekly team meeting today, and I'll also be
communicating with the Ampere Computing firmware team regarding this
issue.

Powered by blists - more mailing lists