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

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

[Andre Przywara]

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.

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?

Cheers,
Andre

 drivers/firmware/smccc/soc_id.c | 2 +-
 include/linux/arm-smccc.h       | 5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/smccc/soc_id.c b/drivers/firmware/smccc/soc_id.c
index c24b3fca1cfe3..8f556df34fc42 100644
--- a/drivers/firmware/smccc/soc_id.c
+++ b/drivers/firmware/smccc/soc_id.c
@@ -60,7 +60,7 @@ static char __init *smccc_soc_name_init(void)
 	 * to the ARM_SMCCC_ARCH_SOC_ID function.  Fetch it if
 	 * available.
 	 */
-	args.a0 = ARM_SMCCC_ARCH_SOC_ID;
+	args.a0 = ARM_SMCCC_ARCH_SOC_ID64;
 	args.a1 = 2;    /* SOC_ID name */
 	arm_smccc_1_2_invoke(&args, &res);
 
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 50b47eba7d015..976c5f8001ff2 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -90,6 +90,11 @@
 			   ARM_SMCCC_SMC_32,				\
 			   0, 2)
 
+#define ARM_SMCCC_ARCH_SOC_ID64						\
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,				\
+			   ARM_SMCCC_SMC_64,				\
+			   0, 2)
+
 #define ARM_SMCCC_ARCH_WORKAROUND_1					\
 	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,				\
 			   ARM_SMCCC_SMC_32,				\
-- 
2.25.1

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

[Sudeep Holla]

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).

-- 
Regards,
Sudeep

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

[Sudeep Holla]

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 ?

-- 
Regards,
Sudeep

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

[Paul Benoit]

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.

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

[Sudeep Holla]

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.

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

-- 
Regards,
Sudeep

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

[Andre Przywara]

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

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

[Paul Benoit]

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