From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>,
Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
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 v11 1/7] firmware: smccc: Add an Arm SMCCC bus
Date: Tue, 15 Sep 2026 14:52:14 +0530 [thread overview]
Message-ID: <yq5ao6dy27jt.fsf@kernel.org> (raw)
In-Reply-To: <20260914222836.GO3968357@nvidia.com>
Jason Gunthorpe <jgg@nvidia.com> writes:
> On Mon, Sep 14, 2026 at 01:32:49PM -0700, Jonathan Cameron wrote:
>> > +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.
>
> Pedenatically the %s is better as it doesn't restrict name to not
> include % characters.
>
>> 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...
>
> Yes, but as written it is OK, and this is a common pattern in the
> kernel. I agree it is fragile tricky..
>
> Still it isn't an urgent reason to change it around, but the best
> pattern is to put the allocate, dev.release=, and device_initialize()
> in one 'alloc' function. Then the other function calls it and always
> unwinds with put_device. Use device_add().
>
> This avoids mixing the different kfree/put_device error unwind regimes
> into the same function..
>
Something like
+static struct arm_smccc_device *arm_smccc_device_alloc(u32 func_id)
+{
+ struct arm_smccc_device *smccc_dev;
+
+ smccc_dev = kzalloc_obj(*smccc_dev);
+ if (!smccc_dev)
+ return NULL;
+
+ 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);
+
+ return smccc_dev;
+}
+
struct arm_smccc_device *arm_smccc_device_register(const char *name, u32 func_id)
{
+ struct arm_smccc_device *smccc_dev;
int ret;
- struct arm_smccc_device *smccc_dev;
if (!name)
return ERR_PTR(-EINVAL);
- smccc_dev = kzalloc_obj(*smccc_dev);
+ smccc_dev = arm_smccc_device_alloc(func_id);
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);
- if (ret) {
- kfree(smccc_dev);
- return ERR_PTR(ret);
- }
+ if (ret)
+ goto err_put_device;
- ret = device_register(&smccc_dev->dev);
- if (ret) {
- put_device(&smccc_dev->dev);
- return ERR_PTR(ret);
- }
+ ret = device_add(&smccc_dev->dev);
+ if (ret)
+ goto err_put_device;
return smccc_dev;
+
+err_put_device:
+ put_device(&smccc_dev->dev);
+ return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(arm_smccc_device_register);
next prev parent reply other threads:[~2026-09-15 9:22 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
2026-09-14 22:28 ` Jason Gunthorpe
2026-09-15 9:22 ` Aneesh Kumar K.V [this message]
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=yq5ao6dy27jt.fsf@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=Suzuki.Poulose@arm.com \
--cc=andre.przywara@arm.com \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jeremy.linton@arm.com \
--cc=jgg@nvidia.com \
--cc=jic23@kernel.org \
--cc=jonathan.cameron@oss.qualcomm.com \
--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.