From: Jonathan Cameron <jonathan.cameron@oss.qualcomm.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, Jason Gunthorpe <jgg@nvidia.com>,
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 v11 1/7] firmware: smccc: Add an Arm SMCCC bus
Date: Mon, 14 Sep 2026 13:32:49 -0700 [thread overview]
Message-ID: <20260914133249.00007d35@oss.qualcomm.com> (raw)
In-Reply-To: <20260914060511.277948-2-aneesh.kumar@kernel.org>
On Mon, 14 Sep 2026 11:35:05 +0530
"Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> wrote:
> SMCCC-discovered firmware services are currently represented by separate
> platform devices, such as smccc_trng and arm-cca-dev. Those devices do not
> represent independent DT/ACPI-described platform resources; they are
> features of the SMCCC firmware interface.
>
> Add an Arm SMCCC bus for services discovered through the SMCCC firmware
> interface. The bus provides SMCCC device and driver registration helpers,
> name-based matching, modalias generation, and a sysfs modalias attribute so
> SMCCC service drivers can bind to discovered firmware services and autoload
> as modules.
>
> Follow-up changes can then register SMCCC firmware services as arm-smccc
> devices instead of creating independent per-feature platform devices.
>
> Based on arm_ffa code
That code has the same issue as below and for bonus points doesn't check
if dev_set_name() succeeds or not.
>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
On tiny bit of fragility inline that I'd suggestion avoiding now rather than
later. Down to dev_set_name() doing allocations in some cases under the hood
that are tricky to tidy up with device_register() being used.
With that tidied up
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
> diff --git a/drivers/firmware/smccc/bus.c b/drivers/firmware/smccc/bus.c
> new file mode 100644
> index 000000000000..caba1a03c997
> --- /dev/null
> +++ b/drivers/firmware/smccc/bus.c
> +
> +struct arm_smccc_device *arm_smccc_device_register(const char *name, u32 func_id)
> +{
> + int ret;
> + struct arm_smccc_device *smccc_dev;
> +
> + if (!name)
> + return ERR_PTR(-EINVAL);
> +
> + smccc_dev = kzalloc_obj(*smccc_dev);
> + if (!smccc_dev)
> + return ERR_PTR(-ENOMEM);
> +
> + smccc_dev->func_id = func_id;
> + smccc_dev->dev.bus = &arm_smccc_bus_type;
> + smccc_dev->dev.release = arm_smccc_release_device;
> +
> + ret = dev_set_name(&smccc_dev->dev, "%s", name);
Does protecting the string defeat the nice underlying const handling?
e.g.
ret = dev_set_name(&smccc_dev->dev, name);
might be better. Not particular important - I only noticed because
you'd often see this between an device_initialize() and device_add()
and then we'd be relying on the device_put() to clean it up.
So as this stands this is fragile as any error paths that later
get added...
> + if (ret) {
> + kfree(smccc_dev);
> + return ERR_PTR(ret);
> + }
> +
here can't free the name allocation.
So I'd just switch this to a split device setup - something like...
smccc_dev = kzalloc_obj(*smccc_dev);
if (!smccc_dev)
return ERR_PTR(-ENOMEM);
smccc_dev->func_id = func_id;
smccc_dev->dev.bus = &arm_smccc_bus_type;
smccc_dev->dev.release = arm_smccc_release_device;
device_initialize(&smccc_dev->dev);
ret = dev_set_name(&smccc_dev->dev, "%s", name);
//up to you whether you care about const string handling.
if (ret) {
put_device(&smcc_dev->dev);
return ret;
}
ret = device_register(&smccc_dev->dev);
if (ret) {
put_device(&smccc_dev->dev);
return ERR_PTR(ret);
}
return smccc_dev;
> + ret = device_register(&smccc_dev->dev);
> + if (ret) {
> + put_device(&smccc_dev->dev);
> + return ERR_PTR(ret);
> + }
> +
> + return smccc_dev;
> +}
> +EXPORT_SYMBOL_GPL(arm_smccc_device_register);
> +
> +void arm_smccc_device_unregister(struct arm_smccc_device *smccc_dev)
> +{
> + if (!smccc_dev)
> + return;
> +
> + device_unregister(&smccc_dev->dev);
> +}
> +EXPORT_SYMBOL_GPL(arm_smccc_device_unregister);
> +
> +static int __init arm_smccc_bus_init(void)
> +{
> + return bus_register(&arm_smccc_bus_type);
> +}
> +subsys_initcall(arm_smccc_bus_init);
next prev parent reply other threads:[~2026-09-14 20:33 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 6:05 [PATCH v11 0/7] Switch Arm SMCCC firmware services to an SMCCC bus Aneesh Kumar K.V (Arm)
2026-09-14 6:05 ` [PATCH v11 1/7] firmware: smccc: Add an Arm " Aneesh Kumar K.V (Arm)
2026-09-14 13:03 ` Catalin Marinas
2026-09-14 20:32 ` Jonathan Cameron [this message]
2026-09-14 22:28 ` Jason Gunthorpe
2026-09-15 9:22 ` Aneesh Kumar K.V
2026-09-15 11:46 ` Jason Gunthorpe
2026-09-23 16:43 ` Jonathan Cameron
2026-09-14 6:05 ` [PATCH v11 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device Aneesh Kumar K.V (Arm)
2026-09-14 13:14 ` Catalin Marinas
2026-09-14 20:39 ` Jonathan Cameron
2026-09-24 12:23 ` Sudeep Holla
2026-09-14 6:05 ` [PATCH v11 3/7] firmware: arm_rmm: Move RSI support out of arch/arm64 Aneesh Kumar K.V (Arm)
2026-09-14 13:18 ` Catalin Marinas
2026-09-14 20:45 ` Jonathan Cameron
2026-09-16 10:58 ` Catalin Marinas
2026-09-14 6:05 ` [PATCH v11 4/7] arm64: realm: Move Realm memory encryption ops to RSI code Aneesh Kumar K.V (Arm)
2026-09-14 13:20 ` Catalin Marinas
2026-09-14 14:50 ` Suzuki K Poulose
2026-09-16 15:21 ` Suzuki K Poulose
2026-09-14 6:05 ` [PATCH v11 5/7] virt: coco: arm-cca-guest: Rename TSM report source file Aneesh Kumar K.V (Arm)
2026-09-14 13:23 ` Catalin Marinas
2026-09-14 15:06 ` Suzuki K Poulose
2026-09-14 20:48 ` Jonathan Cameron
2026-09-14 6:05 ` [PATCH v11 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device Aneesh Kumar K.V (Arm)
2026-09-14 13:42 ` Catalin Marinas
2026-09-14 20:51 ` Jonathan Cameron
2026-09-16 12:46 ` Jason Gunthorpe
2026-09-24 12:24 ` Sudeep Holla
2026-09-14 6:05 ` [PATCH v11 7/7] coco: guest: arm64: Replace dummy CCA device with sysfs ABI Aneesh Kumar K.V (Arm)
2026-09-14 13:48 ` Catalin Marinas
2026-09-14 21:00 ` Jonathan Cameron
2026-09-16 10:57 ` Catalin Marinas
2026-09-16 14:09 ` Aneesh Kumar K.V
2026-09-17 9:56 ` Catalin Marinas
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=20260914133249.00007d35@oss.qualcomm.com \
--to=jonathan.cameron@oss.qualcomm.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=jgg@nvidia.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 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.