Re: [PATCH] firmware: smccc: Fix Arm SMCCC SOC_ID name call

[Andre Przywara <andre.przywara@arm.com>]

Hi Paul,

is there any update on this?
One more thought below ...

On 9/4/25 16:29, Sudeep Holla wrote:
> On Wed, Sep 03, 2025 at 05:38:44PM -0400, Paul Benoit wrote:
>> 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@arm.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?
>>
> 
> Correct, if we have unconditional fallback to the SMC32 call, then there
> is a chance that this issue gets carried into newer Ampere systems as f/w
> gets copied as well as other vendors will also not notice the issue if
> they make similar mistake as the kernel silent makes a SMC32 call.
> 
> We do need details of  the SoC revision and version for which we need to
> apply this workaround/erratum.

So this looks more like a firmware erratum than a SoC specific one, 
right? So I wonder if any SoC specific IDs are really appropriate here. 
Is there some firmware version we can read via DMI or so to identify 
affected systems?
Or shall we use a probably much easier SoC or even MIDR check anyway, 
since it's just a fallback? As in: try smc64, if that fails and if it's 
a core that ever shipped with that affected firmware, try smc32? I think 
there is not much harm in trying those FIDs, so we just limit the scope 
to Ampere cores - even though that's technically not the right method by 
the book?

Cheers,
Andre



> 
>> 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.
> 
> Thanks!
>