All of lore.kernel.org
 help / color / mirror / Atom feed
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 13:01:32 +0300	[thread overview]
Message-ID: <20250729100132.GH402218@unreal> (raw)
In-Reply-To: <DBOFRAMQXK27.2EFPC1T807C2F@kernel.org>

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.

> 
> > +
> >  	ret = dev_set_name(dev, "%s.%s.%d", modname, auxdev->name, auxdev->id);
> >  	if (ret) {
> >  		dev_err(dev, "auxiliary device dev_set_name failed: %d\n", ret);
> > +		ida_free(&auxiliary_id, auxdev->id);
> >  		return ret;
> >  	}
> >  
> >  	ret = device_add(dev);
> > -	if (ret)
> > +	if (ret) {
> >  		dev_err(dev, "adding auxiliary device failed!: %d\n", ret);
> > +		ida_free(&auxiliary_id, auxdev->id);
> > +	}
> >  
> >  	return ret;
> >  }
> >  EXPORT_SYMBOL_GPL(__auxiliary_device_add);
> >  
> > +void auxiliary_device_delete(struct auxiliary_device *auxdev)
> > +{
> > +	ida_free(&auxiliary_id, auxdev->id);
> 
> Hm...I wonder if we should call this from the device's release callback instead.

Yes, you are right.

Thanks

  reply	other threads:[~2025-07-29 10:01 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 [this message]
2025-07-29 10:51     ` Danilo Krummrich
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=20250729100132.GH402218@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.