From: "Danilo Krummrich" <dakr@kernel.org>
To: "Leon Romanovsky" <leon@kernel.org>
Cc: "Sean Anderson" <sean.anderson@linux.dev>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Ira Weiny" <ira.weiny@intel.com>, <linux-kernel@vger.kernel.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
"Dave Ertman" <david.m.ertman@intel.com>
Subject: Re: [PATCH] auxiliary: Automatically generate id
Date: Tue, 29 Jul 2025 12:51:42 +0200 [thread overview]
Message-ID: <DBOHCWV2QIAT.EEGEBRGQ60LX@kernel.org> (raw)
In-Reply-To: <20250729100132.GH402218@unreal>
On Tue Jul 29, 2025 at 12:01 PM CEST, Leon Romanovsky wrote:
> On Tue, Jul 29, 2025 at 11:36:27AM +0200, Danilo Krummrich wrote:
>> On Mon Jul 28, 2025 at 11:10 PM CEST, Sean Anderson wrote:
>> > As it turns out, ids are not allowed to have semantic meaning. Their
>> > only purpose is to prevent sysfs collisions. To simplify things, just
>> > generate a unique id for each auxiliary device. Remove all references to
>> > filling in the id member of the device.
>> >
>> > Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
>> > ---
>> >
>> > drivers/base/auxiliary.c | 32 +++++++++++++++++++++++---------
>> > include/linux/auxiliary_bus.h | 26 ++++++++------------------
>> > 2 files changed, 31 insertions(+), 27 deletions(-)
>> >
>> > diff --git a/drivers/base/auxiliary.c b/drivers/base/auxiliary.c
>> > index dba7c8e13a53..f66067df03ad 100644
>> > --- a/drivers/base/auxiliary.c
>> > +++ b/drivers/base/auxiliary.c
>> > @@ -264,6 +264,8 @@ static const struct bus_type auxiliary_bus_type = {
>> > .pm = &auxiliary_dev_pm_ops,
>> > };
>> >
>> > +static DEFINE_IDA(auxiliary_id);
>>
>> I think this is the correct thing to do, even though the per device IDA drivers
>> typically went for so far produces IDs that are easier to handle when debugging
>> things.
>>
>> > +
>> > /**
>> > * auxiliary_device_init - check auxiliary_device and initialize
>> > * @auxdev: auxiliary device struct
>> > @@ -331,20 +333,37 @@ int __auxiliary_device_add(struct auxiliary_device *auxdev, const char *modname)
>> > return -EINVAL;
>> > }
>> >
>> > + ret = ida_alloc(&auxiliary_id, GFP_KERNEL);
>> > + if (ret < 0) {
>> > + dev_err(dev, "auxiliary device id_alloc fauiled: %d\n", ret);
>> > + return ret;
>> > + }
>> > + auxdev->id = ret;
>>
>> This overwrites the ID number set by various drivers that (still) use the
>> auxiliary_device_init() and auxiliary_device_add() pair.
>>
>> While I agree with the general intent, I think it's a very bad idea to just
>> perform this change silently leaving drivers with their IDA instances not
>> knowing that the set ID numbers do not have an effect anymore.
>>
>> I think this should be multiple steps:
>>
>> (1) Remove the id parameter and force an internal ID only for
>> auxiliary_device_create().
>>
>> (2) Convert applicable drivers (and the Rust abstraction) to use
>> auxiliary_device_create() rather than auxiliary_device_init() and
>> auxiliary_device_add().
>>
>> (3) Treewide change to force an internal ID for all auxiliary devices
>> considering this change in all affected drivers.
>
> I would suggest easier approach.
> 1. Add to the proposal patch, the sed generated line which removes auxdev->id
> assignment in the drivers.
> Something like this from mlx5:
> - sf_dev->adev.id = id;
>
> 2. Add standalone patches to remove not used ida_alloc/ida_free calls
> from the drivers.
I assume you suggest this as an alternative to (3) above? If so, that's what I
meant in (3), I should have written "treewide series" instead of "treewide
change".
Technically (2) is orthogonal, yet I think it's a bit better to do the desired
change right away. Otherwise we end up converting all applicable drivers to
implement the auxiliary device release callback (which we need for a common
ida_free()) first, just to remove it later on when we convert to
auxiliary_device_create().
next prev parent reply other threads:[~2025-07-29 10:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 21:10 Sean Anderson
2025-07-29 9:36 ` Danilo Krummrich
2025-07-29 10:01 ` Leon Romanovsky
2025-07-29 10:51 ` Danilo Krummrich [this message]
2025-07-29 11:11 ` Leon Romanovsky
2025-07-29 11:28 ` Danilo Krummrich
2025-07-29 11:49 ` Leon Romanovsky
2025-07-29 12:31 ` Danilo Krummrich
2025-07-29 12:57 ` Leon Romanovsky
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=DBOHCWV2QIAT.EEGEBRGQ60LX@kernel.org \
--to=dakr@kernel.org \
--cc=david.m.ertman@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=ira.weiny@intel.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=sean.anderson@linux.dev \
/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
all inboxes | Powered by JetHome®