From: Jonathan Cameron <jic23@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Biju Das <biju.das.jz@bp.renesas.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Peter Rosin <peda@axentia.se>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
Andi Shyti <andi.shyti@kernel.org>, Wolfram Sang <wsa@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v7 0/4] Extend device_get_match_data() to struct bus_type
Date: Mon, 28 Aug 2023 14:01:41 +0100 [thread overview]
Message-ID: <20230828140141.220732e0@jic23-huawei> (raw)
In-Reply-To: <CAMuHMdU6LhvnZ5FE_3BxyH7reVi69Rjcircquk=jYZ6-j3cqug@mail.gmail.com>
On Mon, 14 Aug 2023 15:12:24 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Biju,
>
> On Fri, Aug 11, 2023 at 4:46 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > Subject: Re: [PATCH v7 0/4] Extend device_get_match_data() to struct
> > > bus_type
> > >
> > > On Fri, Aug 11, 2023 at 01:27:36PM +0000, Biju Das wrote:
> > > > > On Thu, Aug 10, 2023 at 09:05:10AM +0000, Biju Das wrote:
> > >
> > > ...
> > >
> > > > > I'm good with this approach, but make sure you checked the whole
> > > > > kernel source tree for a such.
> > > >
> > > > Checking against 16 is too short I guess??
> > > >
> > > > drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h has 18 enums.
> > >
> > > So, what does prevent us from moving that tables to use pointers?
> >
> > I think that will lead to ABI breakage(client->name vs id->name)
> >
> > match = device_get_match_data(&client->dev);
> > if (match) {
> > chip_type = (uintptr_t)match;
> > name = client->name;
> > } else if (id) {
> > chip_type = (enum inv_devices)
> > id->driver_data;
> > name = id->name;
> > } else {
> > return -ENOSYS;
> > }
>
> I don't consider that part of the ABI, as e.g. converting from board files
> to DT would change the name.
> In addition, using id->name breaks multiple instances of the same device.
This has always been a mess as I wasn't paying attention a long time back
and we ended up with some client->name entries being used for iio_dev->name
whereas it should be the part number.
Using id->name is correct choice. This is supposed to be the same for multiple
instances of the same device. There is label and a bunch of other options
for differentiating them including their parent devices.
Problem is that is exported to userspace and often used as part of the
matching when a userspace tool is trying to find the device.
We could 'give it a go' by setting the name in teh switch statement in the core code
and hope no one notices but it's not ideal
https://elixir.bootlin.com/linux/latest/source/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c#L1597
Jonathan
>
> I applaud more unification ;-)
>
> Gr{oetje,eeting}s,
>
> Geert
>
next prev parent reply other threads:[~2023-08-28 13:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230804161728.394920-1-biju.das.jz@bp.renesas.com>
[not found] ` <20230805174036.129ffbc2@jic23-huawei>
[not found] ` <OS0PR01MB59220491C7C8AA40BEFAAD82860EA@OS0PR01MB5922.jpnprd01.prod.outlook.com>
[not found] ` <20230806142950.6c409600@jic23-huawei>
[not found] ` <ZNEFjyAloqlkMWn7@smile.fi.intel.com>
[not found] ` <ZNFV+C1HCIRJpbdC@google.com>
[not found] ` <ZNIyrG/2h/PeS9Oz@smile.fi.intel.com>
[not found] ` <20230809182551.7eca502e@jic23-huawei>
2023-08-10 9:05 ` Biju Das
2023-08-10 15:11 ` Andy Shevchenko
2023-08-11 13:27 ` Biju Das
2023-08-11 14:30 ` Andy Shevchenko
2023-08-11 14:46 ` Biju Das
2023-08-14 13:12 ` Geert Uytterhoeven
2023-08-14 13:17 ` Biju Das
2023-08-28 13:01 ` Jonathan Cameron [this message]
2023-08-15 6:44 ` Andy Shevchenko
2023-08-15 6:58 ` Biju Das
2023-08-15 7:06 ` Biju Das
2023-08-15 9:42 ` Andy Shevchenko
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=20230828140141.220732e0@jic23-huawei \
--to=jic23@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=andi.shyti@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=djrscally@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=geert+renesas@glider.be \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=peda@axentia.se \
--cc=rafael@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=wsa@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 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®