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

[Paul Benoit <paul@os.amperecomputing.com>]

On 4/30/2026 10:59 AM, Andre Przywara wrote:
> [You don't often get email from andre.przywara@arm.com. Learn why this 
> is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Paul,
> 
> is there any update on this?
> One more thought below ...
> 

Hi Andre,

Using the incorrect SMC32 vs. the correct SMC64 interface, for SOC_ID
Name, was addressed by Ampere firmware some months back.

In addition to recent firmware now responding to a SMC64 CC SOC_ID Name
request, it will continue to respond to an incorrect/broken SMC32
request and return the SOC_ID Name string packed in 64-bit registers.
This will allow Linux kernels 6.15+, incorrectly using SMC32 to get the
SOC_ID Name, to continue to work with new Ampere firmware versions.

In other words, unless any other vendors also implemented SOC_ID Name as
SMC32 in their firmware, I think we can let the Ampere firmware handle
the SMC32 vs. SMC64 mix-up and keep the handling of it out of the Linux
kernel.

It should now be safe to make the SMC32->SMC64 SOC_ID Name change in
Linux.


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