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

Tue May 19 09:01:25 PDT 2026

Hi Paul, Sudeep,

On 5/18/26 23:14, Paul Benoit wrote:
> On 5/12/2026 10:09 AM, Andre Przywara wrote:
>> Hi Paul,
>>
>> many thanks for the answer, and apologies for the delay (was on 
>> holidays).
>>
>> On 5/1/26 22:14, Paul Benoit wrote:
>>> On 4/30/2026 10:59 AM, Andre Przywara wrote:
>>>> [You don't often get email from andre.przywara at 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.
>>
>> OK, many thanks for the information, that seems to be a good solution.
>>
>>> 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.
>>
>> But I think availability of the machines predates the "some month 
>> back" period you mention above?
>> So it would only work if users would update the firmware?
> 
> Correct.  I had already discussed that case with colleagues at Ampere,
> and, rather than having quirk/errata handling in the Linux kernel, we
> are ok with requiring that systems, with older firmware, be updated
> before running future Linux kernels.  That shouldn't pose a big risk/
> problem as I'm not yet aware of anything besides some of my lscpu
> experiments that use the newish SMC CC SOC_ID Name.

Fair enough, it's indeed not breaking the world if the SOC_ID name call 
doesn't work. And given that most other platforms would be broken, given 
this bug, I guess there are not many people out there relying on it yet.

Sudeep, do you agree to just ignore that case? So the original patch 
would be good to go, I think? Let me know if you need anything from me 
still then.

>>> It should now be safe to make the SMC32->SMC64 SOC_ID Name change in
>>> Linux.
>>
>> So I wonder if would still need a quirk for AmpereOne. I guess we 
>> can't query the TF-A build version easily, and a DMI quirk probably 
>> doesn't work either, judging by the dmidecode output of one machine I 
>> looked at.
>> So I was wondering if we should employ the following algorithm:
>>
>>      - do call with 64-bit FID
>>      - if (ret == -1) && (soc_id == jep106:0a16:0004)
>>          - try 32-bit FID
>>
>> Would that work? That checks for the SoC, not the firmware version, 
>> but seems way easier to implement and would cover all cases.
>>
>> Thoughts?
> 
> If it is deemed necessary to have the SMC32 quirk/fallback handling in
> the Linux kernel, then, yes, it would look something like the above.
> That is the correct soc_id value that you would want for the check.

Thanks for the confirmation! I had this coded up, and tested on the FVP, 
by tweaking TF-A to emulate the Ampere firmware behaviour. But if we 
don't need it, even better.

Cheers,
Andre

>>
>> Cheers,
>> Andre
>>
>>>
>>>
>>>> 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 at 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!
>>>>>
>>>>
>>>
>>
> 