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@xxxxxxxxxxxxxxx> 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
