Re: [PATCH v2] Input: silead - Do not try to directly access the GPIO when using ACPI pm

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, 2017-03-14 at 11:21 +0100, Linus Walleij wrote:
> On Thu, Feb 2, 2017 at 3:24 PM, Gregor Riepl <onitake@gmail.com>
> wrote:
> 
> > > I suppose the Windows driver just works everywhere, right?
> > 
> > Not really, no.
> > AFAIK every vendor builds their own driver using a special
> > configuration
> > utility from Silead.
> > All the device-specific data, including panel parameters and
> > calibration
> > data, is compiled into this driver.
> 
> Isn't that just defeating the whole purpose of ACPI (or any other
> hardware description)?
> 
> Isn't the idea to describe all this in ACPI tables, and that is what
> the
> vendor should be doing rather than compiling in hardcoded things
> into drivers?

> I just see this as another sign that the ACPI "ecosystem" is not
> really working because vendors choose to arbitrarily bypass it like
> this.
> 
> Is it too hard for them to use ACPI or is ACPI lacking the right
> parameters to tweak or what is the real problem?

With _DSD is possible to enhance ACPI tables to cover almost everything,
but there is another issue(s):

a) we still have to cope with old firmwares,

b) Windows is doing things differently, and

c) some vendors are abusing ACPI (existing!) standards.

Here is a dilemma: make user's life miserable with hardware they bought,
or make developers' life miserable to support all that. And the winner
is... vendor which is abusing whatever it wants to!

One recent example I found is a Kontron xBTI x86 board (Linux
compatible!) where they abused ACPI by creating a table that even iasl
can't decode (not a major issue, the table name is just non-standard,
but nevertheless).

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy