On Mon, Aug 21, 2023 at 05:40:05PM +0200, Geert Uytterhoeven wrote: > On Mon, Aug 21, 2023 at 5:25 PM Andy Shevchenko > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > On Mon, Aug 21, 2023 at 03:27:43PM +0200, Geert Uytterhoeven wrote: > > > On Mon, Aug 21, 2023 at 3:04 PM Andy Shevchenko > > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > > On Sun, Aug 20, 2023 at 07:44:00PM +0100, Biju Das wrote: ... > > > > For all your work likes this as I noted in the reply to Guenter that > > > > the couple of the selling points here are: > > > > 1) avoidance of the pointer abuse in OF table > > > > (we need that to be a valid pointer); > > > > > > There is no pointer abuse: both const void * (in e.g. of_device_id) > > > and kernel_ulong_t (in e.g. i2c_device_id) can be used by drivers > > > to store a magic cookie, being either a pointer, or an integer value. > > > The same is true for the various unsigned long and void * "driver_data" > > > fields in subsystem-specific driver structures. > > > > (void *)5 is the abuse of the pointer. > > We carry something which is not a valid pointer from kernel perspective. > > But the data field is not required to be a valid pointer. > What kind and type of information it represents is specific to the driver. Where to find necessary information which is not always an integer constant. For example, for the driver data that has callbacks it can't be invalid pointer. Since OF ID table structure is universal, it uses pointers. Maybe you need to update it to use plain integer instead? I think there is no more sense to continue this. We have to admit we have a good disagreement on this and I do not see any way I can agree with your arguments. Note, I'm fine if you "fix" OF ID structure to use kernel_ulong_t. The only objection there is that it may not carry on the const qualifier, which I personally find being a huge downside of the whole driver_data. I believe you haven't objected that. -- With Best Regards, Andy Shevchenko
