On Tue, Nov 15, 2016 at 3:28 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: >> >>> Apart from that, there's also the discrepancy between hardware >> >>> description (the GPIO is connected to both buttons and LEDs, hence it >> >>> should be described that way in DT) >> >> >> >> Correct, this is where a framework change is needed if we want to allow >> >> both the GPIO keyboard and LED drivers to request the GPIO. >> >> Linus, would this be acceptable to you ? Yes, if: - It is solved in a generic way so that there is a call like gpiod_get_nonexclusive() or similar to get a second handle on a GPIOd someone else is already using. - It is cross-coordinated with the regulator people who have exactly the same problem for fixed GPIO regulators and which is why that code looks like hell. Apart from that, we generally need a way to access LEDs as resources with foo-leds = <&led_foo>; in the device tree just like we can get GPIOs and I hope someone is working on that for this thing... triggers is such a hack. Yours, Linus Walleij
