Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Paul Benoit <paul@os.amperecomputing.com>,
	<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 15:23:58 +0100	[thread overview]
Message-ID: <20250903-great-savvy-bloodhound-38c1ca@sudeepholla> (raw)
In-Reply-To: <20250902172053.304911-1-andre.przywara@arm.com>

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


  reply	other threads:[~2025-09-03 19:07 UTC|newest]

Thread overview: 7+ 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 [this message]
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

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=20250903-great-savvy-bloodhound-38c1ca@sudeepholla \
    --to=sudeep.holla@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=paul@os.amperecomputing.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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