Re: [PATCH v3 3/6] platform/x86: dell-smo8800: Move instantiation of lis3lv02d i2c_client from i2c-i801 to dell-smo8800

["Pali Rohár" <pali@kernel.org>]

On Sunday 23 June 2024 00:43:17 Andy Shevchenko wrote:
> On Sat, Jun 22, 2024 at 6:43 PM Pali Rohár <pali@kernel.org> wrote:
> > On Saturday 22 June 2024 16:20:15 Pali Rohár wrote:
> 
> ...
> 
> > Definition of the table can be simplified by defining a macro which
> > expand to those verbose parts which are being repeating, without need to
> > introduce something "new". E.g.:
> >
> > #define DELL_LIS3LV02D_DMI_ENTRY(product_name, i2c_addr) \
> >         { \
> >                 .matches = {
> >                         DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), \
> >                         DMI_MATCH(DMI_PRODUCT_NAME, product_name), \
> >                 }, \
> >                 .driver_data = (void *)(i2c_addr), \
> 
> I'm not against this as we have a lot of different examples similar to
> this (with maybe other types of ID tables). But what makes me worry is
> the use of (void *) here. Shouldn't it be (const void *) so we exclude
> the (potential) cases of dropping const qualifier?

I do not know what is the best way here for casting short int to void*.
For me it looks strange if such casting is needed. Anyway I think that
in any case casting 16-bit short integer to const void* does not produce
different result as casting to plain (non-const) void*. It is not about
const qualifier but about integer-to-pointer cast, where is dropped
everything to that integer type.

> >         }
> >
> > static const struct dmi_system_id smo8800_lis3lv02d_devices[] = {
> >         DELL_LIS3LV02D_DMI_ENTRY("Latitude E5250", 0x29),
> >         DELL_LIS3LV02D_DMI_ENTRY("Latitude E5450", 0x29),
> >         ...
> >         { }
> > };
> >
> > Any opinion about this?
> 
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko