On Sunday 23 June 2024 00:43:17 Andy Shevchenko wrote:
> On Sat, Jun 22, 2024 at 6:43 PM Pali Rohár <pali@xxxxxxxxxx> 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
