From: Jason Gunthorpe <jgg@nvidia.com>
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
Cc: linux-coco@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Greg KH <gregkh@linuxfoundation.org>,
Jeremy Linton <jeremy.linton@arm.com>,
Jonathan Cameron <jic23@kernel.org>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Will Deacon <will@kernel.org>,
Steven Price <steven.price@arm.com>,
Suzuki K Poulose <Suzuki.Poulose@arm.com>,
Andre Przywara <andre.przywara@arm.com>,
Sudeep Holla <sudeep.holla@kernel.org>
Subject: Re: [PATCH v9 1/7] firmware: smccc: Add an Arm SMCCC bus
Date: Fri, 28 Aug 2026 16:34:37 -0300 [thread overview]
Message-ID: <178794567779.4159892.8785590655735217125.b4-review@b4> (raw)
In-Reply-To: <20260805063255.1638614-2-aneesh.kumar@kernel.org>
> [ ... 143 lines skipped ... ]
> +struct arm_smccc_device *arm_smccc_device_register(const char *name)
> +{
> + int id, ret;
> + struct arm_smccc_device *smccc_dev;
> +
> + if (!name)
> + return ERR_PTR(-EINVAL);
> +
> + id = ida_alloc_min(&arm_smccc_bus_id, 1, GFP_KERNEL);
> + if (id < 0)
> + return ERR_PTR(id);
> +
> + smccc_dev = kzalloc_obj(*smccc_dev);
> + if (!smccc_dev) {
> + ida_free(&arm_smccc_bus_id, id);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + smccc_dev->id = id;
> + if (strscpy(smccc_dev->name, name) < 0) {
> + kfree(smccc_dev);
> + ida_free(&arm_smccc_bus_id, id);
> + return ERR_PTR(-EINVAL);
> + }
> + smccc_dev->dev.bus = &arm_smccc_bus_type;
> + smccc_dev->dev.release = arm_smccc_release_device;
> +
> + ret = dev_set_name(&smccc_dev->dev, "%s-%d", smccc_dev->name, id);
The bus seems well constructed, but this is a little bit odd, was it
deliberate?
For identifying the module alias and labeling the bus devices it is
typical to use a fixed HW value, because it tends to turn into
uAPI. So the hex func_id would have been a logical choice:
.func_id = SMC_RSI_ABI_VERSION,
Ie 0xc4000190 as the device label.
For example lets imagine that ARM defines a call to give a list of
(func_id, version) for everything the FW supports. This would be
great, then no need to probe every item in the table anymore. However
if you define strings here then it doesn't work so well, the string
table all has to be built in..
Though handling ARM's version scheme could be tricky.
Not opposed to this, but think about it carefully since this is
basically making a uABI decision that probably cannot be taken back.
comment about that above the table at least.
What is this idr and name mangling doing? The names have to
be unique because they are 1:1 with func_id, which must be unique by
how SMCCC works, so what is the purpose of the IDR?
Now instead of getting a machine stable device name like c4000190 or
even arm-rsi-dev we get arm-rsi-dev.X where X is unpredictable and
might change on kernel upgrades. That's not cool.
smccc_dev->id isn't used for anything else. Drop it?
> [ ... 47 lines skipped ... ]
> +struct arm_smccc_device {
> + int id;
> + char name[ARM_SMCCC_NAME_SIZE];
> + struct device dev;
> +};
It is common practice to put the containing struct at the top and is a
micro optimization since container_of becomes a NOP. Same for the
driver below.
Why have two copies of name? dev->name is already enough?
--
Jason
next prev parent reply other threads:[~2026-08-28 19:35 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 6:32 [PATCH v9 0/7] Switch Arm SMCCC firmware services to an SMCCC bus Aneesh Kumar K.V (Arm)
2026-08-05 6:32 ` [PATCH v9 1/7] firmware: smccc: Add an Arm " Aneesh Kumar K.V (Arm)
2026-08-28 19:34 ` Jason Gunthorpe [this message]
2026-09-03 8:52 ` Aneesh Kumar K.V
2026-09-03 12:57 ` Jason Gunthorpe
2026-09-03 14:13 ` Sudeep Holla
2026-09-03 14:29 ` Jason Gunthorpe
2026-09-03 14:35 ` Aneesh Kumar K.V
2026-09-03 15:46 ` Jason Gunthorpe
2026-09-03 16:18 ` Sudeep Holla
2026-09-03 18:21 ` Jason Gunthorpe
2026-09-04 5:50 ` Aneesh Kumar K.V
2026-09-04 10:02 ` Sudeep Holla
2026-09-04 13:53 ` Jason Gunthorpe
2026-09-04 14:27 ` Sudeep Holla
2026-09-04 17:50 ` Jason Gunthorpe
2026-08-05 6:32 ` [PATCH v9 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device Aneesh Kumar K.V (Arm)
2026-08-05 11:08 ` Catalin Marinas
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-29 5:54 ` Aneesh Kumar K.V
2026-08-29 19:11 ` Jason Gunthorpe
2026-08-05 6:32 ` [PATCH v9 3/7] firmware: arm_rmm: Move RSI support out of arch/arm64 Aneesh Kumar K.V (Arm)
2026-08-05 11:21 ` Catalin Marinas
2026-08-05 13:05 ` Aneesh Kumar K.V
2026-08-10 10:03 ` Suzuki K Poulose
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-29 5:58 ` Aneesh Kumar K.V
2026-08-05 6:32 ` [PATCH v9 4/7] arm64: realm: Move Realm memory encryption ops to RSI code Aneesh Kumar K.V (Arm)
2026-08-10 10:12 ` Suzuki K Poulose
2026-08-10 12:15 ` Aneesh Kumar K.V
2026-08-05 6:32 ` [PATCH v9 5/7] virt: coco: arm-cca-guest: Rename TSM report source file Aneesh Kumar K.V (Arm)
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-29 6:02 ` Aneesh Kumar K.V
2026-08-29 19:07 ` Jason Gunthorpe
2026-08-05 6:32 ` [PATCH v9 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device Aneesh Kumar K.V (Arm)
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-29 6:12 ` Aneesh Kumar K.V
2026-08-29 19:13 ` Jason Gunthorpe
2026-08-05 6:32 ` [PATCH v9 7/7] coco: guest: arm64: Replace dummy CCA device with sysfs ABI Aneesh Kumar K.V (Arm)
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-05 9:51 ` [PATCH v9 0/7] Switch Arm SMCCC firmware services to an SMCCC bus Catalin Marinas
2026-08-05 12:22 ` Aneesh Kumar K.V
2026-08-10 9:35 ` Aneesh Kumar K.V
2026-08-10 10:24 ` Will Deacon
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=178794567779.4159892.8785590655735217125.b4-review@b4 \
--to=jgg@nvidia.com \
--cc=Suzuki.Poulose@arm.com \
--cc=andre.przywara@arm.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jeremy.linton@arm.com \
--cc=jic23@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mark.rutland@arm.com \
--cc=steven.price@arm.com \
--cc=sudeep.holla@arm.com \
--cc=sudeep.holla@kernel.org \
--cc=will@kernel.org \
/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