lkml.org 
[lkml]   [2015]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] gpio: support for GPIO forwarding
On Mon, Jan 19, 2015 at 02:59:54PM +0900, Alexandre Courbot 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).
>
> Also I don't think any new functions is actually needed: on an ACPI
> system we can safely assume that the platform lookup tables are not
> used at all. So, although it is a hack as well, you can just call
> gpiod_add_lookup_table() with a runtime-built table from the driver
> that needs to pass the GPIO so the receipient can receive it through
> the lookup table fallback gpiod_get() uses if no GPIO is defined via
> ACPI.

Unfortunately that would require us to determine details about the
gpios in the consumer driver, details like the chip_label, chip_hwnum
and flags. Stuff that I don't think the consumers should touch.

In order to dig those out of the gpio description, the driver would
either need to include linux/gpio/machine.h, linux/gpio/driver.h and
linux/gpio/consumer.h or we would need to add helper functions to
gpiolib.c that do the digging for us. Most likely it would not be
possible to avoid the helpers. We would in any case have to add
removal function for the lookups and gpiod_add_lookup_table would need
to be exported.

It simply ended up being less of a hack to add the simple function
explicitly for consumers to be used in a case like this for creating
the lookups.

Br,

--
heikki


\
 
 \ /
  Last update: 2015-01-19 13:01    [W:0.134 / U:8.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site