On Mon, 7 Aug 2023 13:37:12 -0700 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Mon, Aug 07, 2023 at 05:54:07PM +0300, Andy Shevchenko wrote: > > On Sun, Aug 06, 2023 at 02:29:50PM +0100, Jonathan Cameron wrote: > > > On Sat, 5 Aug 2023 17:42:21 +0000 > > > Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote: > > > > > On Fri, 4 Aug 2023 17:17:24 +0100 > > > > > Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote: > > > > ... > > > > > > + * Besides the fact that some drivers abuse the device ID driver_data type > > > > + * and claim it to be integer, for the bus specific ID tables the driver_data > > > > + * may be defined as kernel_ulong_t. For these tables 0 is a valid response, > > > > + * but not for this function. It's recommended to convert those either to avoid > > > > + * 0 or use a real pointer to the predefined driver data. > > > > > We still need to maintain consistency across the two tables, which > > > is a stronger requirement than avoiding 0. > > > > True. Any suggestion how to amend the above comment? Because the documentation > > makes sense on its own (may be split from the series?). > > > > > Some drivers already do that by forcing the enum used to start at 1 which > > > doesn't solver the different data types issue. > > > > And some maintainers do not want to see non-enum values in i2c ID table. > > *Shrug*. > > 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. Good idea. Though I suspect there may still be nasty cases. People have been known to put chip ID values in these fields so that they can then match them against a who am I register as a 'detect it's the right part' check. No idea if we have any drivers doing that but if there are hopefully not too many! Jonathan > > Thanks. >
