From: Paul Benoit <paul@os•amperecomputing.com>
To: Sudeep Holla <sudeep.holla@arm•com>,
Andre Przywara <andre.przywara@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: Wed, 3 Sep 2025 17:38:44 -0400 [thread overview]
Message-ID: <cc8000c0-e457-4bfc-94de-aeeddacab23b@os.amperecomputing.com> (raw)
In-Reply-To: <20250903-loutish-orangutan-of-experience-3dcfda@sudeepholla>
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?
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.
next prev parent reply other threads:[~2025-09-04 2:10 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 [this message]
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
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=cc8000c0-e457-4bfc-94de-aeeddacab23b@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