Re: Silead DMI driver

[Jean Delvare <jdelvare@suse.de>]

On Mon, 24 Apr 2017 14:48:16 +0300, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at 13:23 +0200, Jean Delvare wrote:
> > I'm looking at drivers/platform/x86/silead_dmi.c which is being added
> > to kernel v4.11 and I do not like what I see.
> 
> I don't like it either by some other reasons.
> 
> > I have to say I don't understand the whole complexity of the design.
> > As I understand it, the properties which are being added are only
> > consumed by the "silead" touchscreen driver. I see no necessity to add
> > the missing properties before that driver is even loaded. Can't you
> > just look for the ACPI companion device at the time the silead driver
> > tries to bind to the i2c device, and add the missing properties before
> > performing the actual probe? This would be so much simpler. What am I
> > missing?
> 
> As far as I understand it would be as simple as adding a quirk in actual
> driver (touchscreen), but there is strong objection of adding quirks to
> the drivers/input/* from Dmitry as I noticed during discussion [1] about
> GPIO ACPI library fixes I'm working on.
> 
> [1] https://lkml.org/lkml/2017/4/4/593

Thanks for the pointer Andy. OK, I can understand the argument of
Dmitry that platform-specific quirks do not belong to the device
drivers, even though in practice I'm not sure the cost of having a
separate platform driver for the purpose is always worth it - depends
on how "popular" the device is, I suppose.

But still, this can't justify non-modular platform code that will run
on every X86 system out there. Any piece of platform-specific quirks,
we should be able to build as a module, otherwise it simply doesn't
scale. PCI quirks and such are enough pain already without inventing
more flavors of bloat :-(

-- 
Jean Delvare
SUSE L3 Support