Re: [PATCH v3 09/16] platform/x86: x86-android-tablets: Add include defining struct dmi_system_id

[Uwe Kleine-König (The Capable Hub)]

Hello Ilpo,

On Mon, Jun 29, 2026 at 02:38:35PM +0300, Ilpo Järvinen wrote:
> On Sun, 28 Jun 2026, Uwe Kleine-König (The Capable Hub) wrote:
> 
> > Currently <linux/i2c.h> includes <linux/mod_devicetable.h> transitively
> > which ensures that struct dmi_system_id is defined in
> > drivers/platform/x86/x86-android-tablets/x86-android-tablets.h. However
> > this include in <linux/i2c.h> will be replaced by one for i2c_device_id
> > only. To ensure that dmi_system_id is available add the include for that
> > explicitly.
> > 
> > Acked-by: Danilo Krummrich <dakr@xxxxxxxxxx>
> > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@xxxxxxxxxxxx>
> > ---
> >  drivers/platform/x86/x86-android-tablets/x86-android-tablets.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
> > index 2498390958ad..c756961ae5fd 100644
> > --- a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
> > +++ b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
> > @@ -13,6 +13,7 @@
> >  #include <linux/gpio/consumer.h>
> >  #include <linux/i2c.h>
> >  #include <linux/irqdomain_defs.h>
> > +#include <linux/device-id/dmi.h>
> >  #include <linux/spi/spi.h>
> >  
> >  struct gpio_desc;
> 
> Indirect include patchs are never a good idea as it always makes header 
> reorganizations minefield. So for this change,
> 
> Acked-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
> 
> 
> When it comes to the series, I certainly like the direction it goes very 
> much (never have been fan of mod_devicetable.h) but I'd have preferred 
> stepwise approach over trying to introduce it to some mid-rc.

The hurdle here is that at least the header part isn't easily
automateable. (Well it is, but the script that I have now to check all
.c files already takes longer than an hour to run. I guess it's not as
optimal as it could, but still.) And so getting this ready for inclusion
in next and keeping it up to date until the merge window opens is a
tough job.

The further downside is that each modification to one of the highly used
headers is expensive (in rebuild time) when these are merged one after
another (or when bisecting). So getting these changes in in one batch is
beneficial.

So while I agree with your preference, I don't think it's feasible.

Best regards
Uwe

Attachment: signature.asc
Description: PGP signature