On Thu, Jan 23, 2020 at 07:35:06PM -0600, Rob Herring wrote: > On Thu, Jan 23, 2020 at 4:25 PM Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > > > Hi Rob, > > > > On Thu, Jan 23, 2020 at 03:42:22PM -0600, Rob Herring wrote: > > > Convert the gpio-keys and gpio-keys-polled bindings to a DT schema. As > > > both bindings are almost the same, combine them into a single schema. > > > > > > The binding said 'interrupts' was required, but testing on dts files > > > showed that it isn't required. > > > > > > 'linux,input-value' was only documented for gpio-keys-polled, but there > > > doesn't seem to be any reason for it to be specific to that. > > > > Actually, there is: with gpio-keys-polled we take a "snapshot" of the > > entire device state, so we know when to generate a 0 event (the example > > we have a device with several GPIOs with values assigned 1, 2, 3, 4, 5.. > > values, when one of the gpios is active we generate event with given > > value, when all are inactive we generate 0 event). This does not work > > for interrupt-only driven device. > > Okay, it wasn't clear to me reading the binding doc. I'll make it conditional. Actually, I think we can make it usable in interrupt-driver driver. For EV_REL events we do not need to "go back to 0", and for EV_ABS, if desired, we could allow specifying an option to scan all GPIOs on any interrupt. This obviously will not work for pure interrupt devices (where we do not have GPIOs). Thanks. -- Dmitry
