From: Leon Romanovsky <leon@kernel.org>
To: Danilo Krummrich <dakr@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 14:11:30 +0300 [thread overview]
Message-ID: <20250729111130.GI402218@unreal> (raw)
In-Reply-To: <DBOHCWV2QIAT.EEGEBRGQ60LX@kernel.org>
On Tue, Jul 29, 2025 at 12:51:42PM +0200, Danilo Krummrich wrote:
> 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".
I would say for all steps. Very important reason to use
auxiliary_device_init() and not auxiliary_device_create() is to bind
custom release callback, which is needed to release private data.
In addition, complex devices embed struct auxiliary_device in their
internal struct to rely on container_of to access the data.
See mlx5_sf_dev_add() in drivers/net/ethernet/mellanox/mlx5/core/sf/dev/dev.c
as an example.
>
> 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().
My expectation is to see extension of driver/base/core.c. Something like that:
diff --git a/drivers/base/core.c b/drivers/base/core.c
index cbc0099d8ef24..63847c84dbdc0 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2560,8 +2560,10 @@ static void device_release(struct kobject *kobj)
kfree(dev->dma_range_map);
- if (dev->release)
+ if (dev->release) {
+ dev->bus_specific_cleanup(dev);
dev->release(dev);
+ }
else if (dev->type && dev->type->release)
dev->type->release(dev);
else if (dev->class && dev->class->dev_release)
(END)
next prev parent reply other threads:[~2025-07-29 11:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 21:10 [PATCH] auxiliary: Automatically generate id Sean Anderson
2025-07-29 9:36 ` Danilo Krummrich
2025-07-29 10:01 ` Leon Romanovsky
2025-07-29 10:51 ` Danilo Krummrich
2025-07-29 11:11 ` Leon Romanovsky [this message]
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=20250729111130.GI402218@unreal \
--to=leon@kernel.org \
--cc=dakr@kernel.org \
--cc=david.m.ertman@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=ira.weiny@intel.com \
--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 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.