On Wed, Aug 31, 2022 at 2:28 PM Sa, Nuno <Nuno.Sa@xxxxxxxxxx> wrote: > > > From: Linus Walleij <linus.walleij@xxxxxxxxxx> > > Sent: Wednesday, August 31, 2022 2:24 PM > > To: Sa, Nuno <Nuno.Sa@xxxxxxxxxx> > > Cc: linux-input@xxxxxxxxxxxxxxx; linux-gpio@xxxxxxxxxxxxxxx; > > devicetree@xxxxxxxxxxxxxxx; Krzysztof Kozlowski > > <krzysztof.kozlowski+dt@xxxxxxxxxx>; Hennerich, Michael > > <Michael.Hennerich@xxxxxxxxxx>; Bartosz Golaszewski > > <brgl@xxxxxxxx>; Andy Shevchenko <andy.shevchenko@xxxxxxxxx>; > > Rob Herring <robh+dt@xxxxxxxxxx>; Dmitry Torokhov > > <dmitry.torokhov@xxxxxxxxx> > > Subject: Re: [PATCH v3 01/10] input: keyboard: adp5588-keys: support > > gpi key events as 'gpio keys' > > > > [External] > > > > On Thu, Jul 21, 2022 at 10:03 AM Nuno Sá <nuno.sa@xxxxxxxxxx> > > wrote: > > > > > This change replaces the support for GPIs as key event generators. > > > Instead of reporting the events directly, we add a gpio based irqchip > > > so that these events can be consumed by keys defined in the gpio- > > keys > > > driver (as it's goal is indeed for keys on GPIOs capable of generating > > > interrupts). With this, the gpio-adp5588 driver can also be dropped. > > > > > > The basic idea is that all the pins that are not being used as part of > > > the keymap matrix can be possibly requested as GPIOs by gpio-keys > > > (it's also fine to use these pins as plain interrupts though that's not > > > really the point). > > > > > > Since the gpiochip now also has irqchip capabilities, we should only > > > remove it after we free the device interrupt (otherwise we could, in > > > theory, be handling GPIs interrupts while the gpiochip is concurrently > > > removed). Thus the call 'adp5588_gpio_add()' is moved and since the > > > setup phase also needs to come before making the gpios visible, we > > also > > > need to move 'adp5588_setup()'. > > > > > > While at it, always select GPIOLIB so that we don't need to use #ifdef > > > guards. > > > > > > Signed-off-by: Nuno Sá <nuno.sa@xxxxxxxxxx> > > > > Is there any input-related content in the driver after this or > > should the whole driver just be moved over to drivers/gpio > > and replace the old GPIO driver that you delete in patch > > 2? > > > > Hi, > > Yes there is... The main usage for the device is to use it as a > matrix keypad. However, all the keys that are not used will be then > exposed through a gpiochip to be consumed for example by gpio-keys OK then, just checking. Let's keep it here for now, consider the MFD approach suggested by Andy (splitting out the gpio chip and input parts in two files in drivers/gpio and drivers/input) for the long run. Yours, Linus Walleij
