[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZzCX0O1wX=W5RbjLcqOF_R3HMTT1w59oFu=JfPauLNuw@mail.gmail.com>
Date: Tue, 20 Jan 2015 13:16:06 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Alexandre Courbot <gnurou@...il.com>
Cc: Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Darren Hart <dvhart@...ux.intel.com>,
Arnd Bergmann <arnd@...db.de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [RFC PATCH] gpio: support for GPIO forwarding
On Mon, Jan 19, 2015 at 6:59 AM, Alexandre Courbot <gnurou@...il.com> wrote:
> I am not really fond of this idea since it adds complexity to the
> (already too complex) GPIO lookup, and only solves to a local level
> (GPIO) what is a more global problem (bad ACPI tables that can affect
> any subsystem).
(...)
> it
> seems more to-the-point to find a way to fix/patch the ACPI tables at
> runtime, if that is possible at all, to provide a more general
> solution to this issue.
This is my position as well, until proven that this cannot be done.
In device tree the same mechanism is called "device tree overlays"
and I just have some vague feeling that such stuff is patched around in
some Intel platforms already, but maybe that involves replacing
the whole DSDT from userspace, surely the mechanism can be
refined?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists