Messages in this thread | | | Subject | Re: [PATCH v1 6/8] gpio: acpi: Explain how to get GPIO descriptors in ACPI case | From | Andy Shevchenko <> | Date | Tue, 04 Apr 2017 20:59:11 +0300 |
| |
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@linux.intel.com> Intel Finland Oy
| |