Re: [PATCH v1 6/8] gpio: acpi: Explain how to get GPIO descriptors in ACPI case

[Andy Shevchenko]

On Tue, 2017-04-04 at 10:31 -0700, Dmitry Torokhov wrote:
> On Tue, Apr 04, 2017 at 07:11:17PM +0300, Andy Shevchenko wrote:
> > On Wed, 2017-03-29 at 18:04 +0300, Andy Shevchenko wrote:
> > > On Wed, 2017-03-29 at 00:12 -0700, Dmitry Torokhov wrote:
> > > > On Tue, Mar 28, 2017 at 07:39:23PM +0300, Andy Shevchenko wrote:
> > > > > On Thu, 2017-03-23 at 13:28 -0700, Dmitry Torokhov wrote:
> > > > > > On Thu, Mar 23, 2017 at 09:46:16PM +0200, Andy Shevchenko
> > > > > > wrote:

> > > Otherwise I'm reading something like this:
> > > "If we have platform driverX.c which has DT/platform and ACPI
> > > enumeration, we must split ACPI part out, duplicate a lot of code
> > > and
> > > use platform driver as a library."
> 
> No. You need to split the part that augments incomplete ACPI data, and
> move it somewhere (drivers/platform/x86/<platform>-crap.c; the driver
> stays the same: a driver that is useful across multiple platforms.

> > > Is that what you mean?

So, it means to spread IDs in two places. Looking into silead_dmi.c I
can say it looks as a hack, we aren't supposed to use "ACPIXXXX:YY" in
the drivers AFAIK. Besides the fact of notifier and arch_initcall().

It indeed feels like a crap and looks like a crap.

Rafael, Mika, what are your opinions about proposed approach?

> > > P.S. This all _CRS fallback shouldn't be allowed in the first
> > > place.
> 
> It does work in many cases. By disallowing it completely you force
> much
> more platform stuff knowledge in the kernel, whereas before you needed
> to deal with exceptions.

It works due to luck, not otherwise.


-- 
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Intel Finland Oy