From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
"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: Thu, 10 Aug 2023 18:11:49 +0300 [thread overview]
Message-ID: <ZNT+NY99n7y3abwa@smile.fi.intel.com> (raw)
In-Reply-To: <OS0PR01MB59221A1ADB67E96E9E39D0198613A@OS0PR01MB5922.jpnprd01.prod.outlook.com>
On Thu, Aug 10, 2023 at 09:05:10AM +0000, Biju Das wrote:
> > On Tue, 8 Aug 2023 15:18:52 +0300
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > On Mon, Aug 07, 2023 at 01:37:12PM -0700, Dmitry Torokhov wrote:
> > > > On Mon, Aug 07, 2023 at 05:54:07PM +0300, Andy Shevchenko wrote:
...
> > > > So in legacy ID lookup path we can safely assume that values below
> > > > 4096 are scalars and return NULL from the new
> > > > device_get_match_data(). This way current drivers using the values
> > > > as indices or doing direct comparisons against them can continue
> > > > doing manual look up and using them as they see fit. And we can
> > convert the drivers at our leisure.
> > >
> > > It's a good idea, but I believe will be received as hack.
> > > But why not to try? We indeed have an error pointers for the last page
> > > and NULL (which is only up to 16 IIRC) and reserved space in the first
> > > page. To be more robust I would check all enums that are being used in
> > > I2C ID tables for maximum value and if that is less than 16, use
> > > ZERO_OR_NULL_PTR() instead of custom stuff.
> > >
> > See iio/adc/max1363 example that has 37ish.
> >
> > Could tidy that one up first and hopefully not find any others that are in
> > subsystems not keen on the move away from enums.
>
> If there is no objection, I can fix this using i2c_get_match_data() for
> iio/adc/max1363 and device_match_data() will return ZERO_OR_NULL_PTR()
> if max enum ID in the ID lookup table is less than 16. And the drivers
> that use legacy ID's will fallback to ID lookup. So that there won't be
> any regression.
I'm good with this approach, but make sure you checked the whole kernel source
tree for a such.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-08-10 15:12 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 16:17 [PATCH v7 0/4] Extend device_get_match_data() to struct bus_type Biju Das
2023-08-04 16:17 ` [PATCH v7 1/4] drivers: fwnode: " Biju Das
2023-08-05 16:40 ` [PATCH v7 0/4] " Jonathan Cameron
2023-08-05 17:42 ` Biju Das
2023-08-06 13:29 ` Jonathan Cameron
2023-08-06 16:27 ` Biju Das
2023-08-07 14:54 ` Andy Shevchenko
2023-08-07 19:45 ` Jonathan Cameron
2023-08-08 12:14 ` Andy Shevchenko
2023-08-07 20:37 ` Dmitry Torokhov
2023-08-08 12:18 ` Andy Shevchenko
[not found] ` <20230809182551.7eca502e@jic23-huawei>
2023-08-10 9:05 ` Biju Das
2023-08-10 15:11 ` Andy Shevchenko [this message]
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
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
2023-08-10 15:04 ` Andy Shevchenko
2023-08-08 15:16 ` Jonathan Cameron
2023-08-14 13:01 ` Geert Uytterhoeven
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=ZNT+NY99n7y3abwa@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andi.shyti@kernel.org \
--cc=biju.das.jz@bp.renesas.com \
--cc=djrscally@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=jic23@kernel.org \
--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