From: Paul Benoit <paul@os•amperecomputing.com>
To: Andre Przywara <andre.przywara@arm•com>,
Sudeep Holla <sudeep.holla@arm•com>
Cc: Mark Rutland <mark.rutland@arm•com>,
Lorenzo Pieralisi <lpieralisi@kernel•org>,
linux-arm-kernel@lists•infradead.org,
linux-kernel@vger•kernel.org
Subject: Re: [PATCH] firmware: smccc: Fix Arm SMCCC SOC_ID name call
Date: Mon, 18 May 2026 17:14:35 -0400 [thread overview]
Message-ID: <2ec94be2-19f9-46c5-a2ad-78711ddfeef8@os.amperecomputing.com> (raw)
In-Reply-To: <506bf1b9-dfc4-4717-b26b-835c331d23c4@arm.com>
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@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.
>
>> 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.
>
> 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@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!
>>>>
>>>
>>
>
next prev parent reply other threads:[~2026-05-18 21:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 17:20 [PATCH] firmware: smccc: Fix Arm SMCCC SOC_ID name call Andre Przywara
2025-09-03 14:23 ` Sudeep Holla
2025-09-03 14:49 ` Sudeep Holla
2025-09-03 21:38 ` Paul Benoit
2025-09-04 14:29 ` Sudeep Holla
2026-04-30 14:59 ` Andre Przywara
2026-05-01 20:14 ` Paul Benoit
2026-05-12 14:09 ` Andre Przywara
2026-05-18 21:14 ` Paul Benoit [this message]
2026-05-19 16:01 ` Andre Przywara
2026-05-21 14:18 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ec94be2-19f9-46c5-a2ad-78711ddfeef8@os.amperecomputing.com \
--to=paul@os$(echo .)amperecomputing.com \
--cc=andre.przywara@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=lpieralisi@kernel$(echo .)org \
--cc=mark.rutland@arm$(echo .)com \
--cc=sudeep.holla@arm$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox