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 -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html