From: Sudeep Holla <sudeep.holla@arm.com>
To: Paul Benoit <paul@os.amperecomputing.com>,
Mark Rutland <mark.rutland@arm.com>
Cc: <linux-kernel@vger.kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4] firmware: smccc: Support optional Arm SMC SOC_ID name
Date: Mon, 3 Mar 2025 14:45:28 +0000 [thread overview]
Message-ID: <Z8XAiMSoaOmR5JxY@bogus> (raw)
In-Reply-To: <Z8W6HXZy46K7ebWe@J2N7QTR9R3.cambridge.arm.com>
On Mon, Mar 03, 2025 at 02:18:05PM +0000, Mark Rutland wrote:
> Hi Paul,
>
> This looks generally good with a couple of minor nits.
>
> On Tue, Feb 18, 2025 at 04:59:32PM -0800, Paul Benoit wrote:
> > Issue Number 1.6 of the Arm SMC Calling Convention introduces an optional
> > SOC_ID name string. If implemented, point the 'machine' field of the SoC
> > Device Attributes at this string so that it will appear under
> > /sys/bus/soc/devices/soc0/machine.
> >
> > On Arm SMC compliant SoCs, this will allow things like 'lscpu' to
> > eventually get a SoC provider model name from there rather than each
> > tool/utility needing to get a possibly inconsistent, obsolete, or incorrect
> > model/machine name from its own hardcoded model/machine name table.
> >
> > Signed-off-by: Paul Benoit <paul@os.amperecomputing.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > ---
[...]
> > +static char __init *smccc_soc_name_init(void)
> > +{
> > + struct arm_smccc_1_2_regs args;
> > + struct arm_smccc_1_2_regs res;
> > + size_t len;
> > +
> > + /*
> > + * Issue Number 1.6 of the Arm SMC Calling Convention
> > + * specification introduces an optional "name" string
> > + * to the ARM_SMCCC_ARCH_SOC_ID function. Fetch it if
> > + * available.
> > + */
> > + args.a0 = ARM_SMCCC_ARCH_SOC_ID;
> > + args.a1 = 2; /* SOC_ID name */
> > + arm_smccc_1_2_invoke(&args, &res);
> > + if ((u32)res.a0 == 0) {
> > + const unsigned int regsize = sizeof(res.a1);
> > +
> > + /*
> > + * Copy res.a1..res.a17 to the smccc_soc_id_name string
> > + * 8 bytes at a time. As per Issue 1.6 of the Arm SMC
> > + * Calling Convention, the string will be NUL terminated
> > + * and padded, from the end of the string to the end of the
> > + * 136 byte buffer, with NULs.
> > + */
> > + str_fragment_from_reg(smccc_soc_id_name + 0*regsize, res.a1);
> > + str_fragment_from_reg(smccc_soc_id_name + 1*regsize, res.a2);
> > + str_fragment_from_reg(smccc_soc_id_name + 2*regsize, res.a3);
> > + str_fragment_from_reg(smccc_soc_id_name + 3*regsize, res.a4);
> > + str_fragment_from_reg(smccc_soc_id_name + 4*regsize, res.a5);
> > + str_fragment_from_reg(smccc_soc_id_name + 5*regsize, res.a6);
> > + str_fragment_from_reg(smccc_soc_id_name + 6*regsize, res.a7);
> > + str_fragment_from_reg(smccc_soc_id_name + 7*regsize, res.a8);
> > + str_fragment_from_reg(smccc_soc_id_name + 8*regsize, res.a9);
> > + str_fragment_from_reg(smccc_soc_id_name + 9*regsize, res.a10);
> > + str_fragment_from_reg(smccc_soc_id_name + 10*regsize, res.a11);
> > + str_fragment_from_reg(smccc_soc_id_name + 11*regsize, res.a12);
> > + str_fragment_from_reg(smccc_soc_id_name + 12*regsize, res.a13);
> > + str_fragment_from_reg(smccc_soc_id_name + 13*regsize, res.a14);
> > + str_fragment_from_reg(smccc_soc_id_name + 14*regsize, res.a15);
> > + str_fragment_from_reg(smccc_soc_id_name + 15*regsize, res.a16);
> > + str_fragment_from_reg(smccc_soc_id_name + 16*regsize, res.a17);
>
> Please get rid of 'regsize' and use '8' directly. This only exists for
> arm64, where the registeres are 8 bytes, and the comment immediately
> above refers to "8 bytes" specifically anyway, so 'regsize' only serves
> to make this harder to read.
>
> It'd be a bit clearer as:
>
> str_fragment_from_reg(smccc_soc_id_name + 8 * 0, res.a1);
> str_fragment_from_reg(smccc_soc_id_name + 8 * 1, res.a2);
> ...
> str_fragment_from_reg(smccc_soc_id_name + 8 * 15, res.a16);
> str_fragment_from_reg(smccc_soc_id_name + 8 * 16, res.a17);
>
> Sudeep, are you happy to fix that up when applying?
>
> > +
> > + len = strnlen(smccc_soc_id_name, sizeof(smccc_soc_id_name));
> > + if (len) {
> > + if (len == sizeof(smccc_soc_id_name))
> > + pr_warn(FW_BUG "Ignoring improperly formatted Name\n");
>
> It's odd that 'Name' is capitalized here. Not a big deal, but it doesn't
> look quite right.
>
I can fix both of these and apply. No need to repost.
--
Regards,
Sudeep
next prev parent reply other threads:[~2025-03-03 14:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-14 3:04 [PATCH] firmware: smccc: Support optional Arm SMC SOC_ID name Paul Benoit
2024-11-14 12:22 ` Mark Rutland
2024-11-25 22:52 ` Paul Benoit
2024-11-17 0:12 ` kernel test robot
2024-11-17 0:56 ` kernel test robot
2024-12-03 21:28 ` [PATCH v2] " Paul Benoit
2024-12-04 11:22 ` kernel test robot
2024-12-04 12:26 ` kernel test robot
2024-12-18 0:13 ` [PATCH v3] " Paul Benoit
2025-02-10 12:13 ` Sudeep Holla
2025-02-14 22:59 ` Paul Benoit
2025-02-19 0:59 ` [PATCH v4] " Paul Benoit
2025-03-03 14:18 ` Mark Rutland
2025-03-03 14:45 ` Sudeep Holla [this message]
2025-03-03 17:07 ` Paul Benoit
2025-03-04 10:58 ` 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=Z8XAiMSoaOmR5JxY@bogus \
--to=sudeep.holla@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.