Re: [PATCH] [v2] input: gpio-keys: make legacy gpiolib optional

[Arnd Bergmann]

On Tue, Apr 28, 2026, at 06:14, Dmitry Torokhov wrote:
> On Mon, Apr 27, 2026 at 04:33:49PM +0200, Arnd Bergmann wrote:
>> 
>> The two Rohm PMIC drivers use a gpio-keys device without an actual GPIO,
>> passing an IRQ number instead. In order to keep this working both with
>> and with CONFIG_GPIOLIB_LEGACY, change the gpio-keys driver to ignore
>> the gpio number if an IRQ is passed.
>> 
>> Link: https://lore.kernel.org/all/b3c94552-c104-42e3-be15-7e8362e8039e@xxxxxxxxx/
>> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
>> ---
>> v2: skip the fake GPIO number passing from mfd
>> ---
>>  drivers/input/keyboard/gpio_keys.c        | 7 ++++---
>>  drivers/input/keyboard/gpio_keys_polled.c | 2 ++
>>  drivers/mfd/rohm-bd71828.c                | 1 -
>>  drivers/mfd/rohm-bd718x7.c                | 1 -
>
> Let's see if my patches to rohm drivers will get accepted and then maybe
> we can remove legacy gpio API from gpio-keys altogether.

I think it would be good to still merge the drivers/input
parts of my patch. Since CONFIG_GPIOLIB_LEGACY is still set
unconditionally at the moment, that should work fine as long
as your patches for the rohm drivers get merged before
we turn off CONFIG_GPIOLIB_LEGACY for modern platforms.

In linux-next, I see these users of the legacy gpio-keys platform
data remaining:

arch/arm/mach-mv78xx0/buffalo-wxl-setup.c
arch/arm/mach-orion5x/dns323-setup.c
arch/arm/mach-orion5x/mv2120-setup.c
arch/arm/mach-orion5x/net2big-setup.c
arch/arm/mach-orion5x/ts209-setup.c
arch/arm/mach-orion5x/ts409-setup.c
arch/arm/mach-s3c/mach-crag6410.c
arch/arm/mach-sa1100/assabet.c
arch/arm/mach-sa1100/collie.c
arch/arm/mach-sa1100/h3xxx.c
arch/mips/alchemy/devboards/db1300.c
arch/mips/bcm47xx/buttons.c
arch/sh/boards/mach-rsk/devices-rsk7203.c
arch/sh/boards/mach-x3proto/setup.c
drivers/input/misc/soc_button_array.c
drivers/mfd/ucb1x00-assabet.c

Do you already have patches for more of these? I would like to
kill off mv78xx0, orion5x and sa1100 board files (including
the ucb1x00-assabet mfd driver) soon, but that still leaves s3c,
alchemy, bcm47xx, rsk and x3proto. These platforms are in
varying states of disrepair, maybe a few more of those
can be removed instead of converted. I know that Mark
Brown is still using the s3c board, and Waldemar Brodkorb
was recently working on restoring bcm47xx into a usable
state.

I assume you'll take care of the soc_button_array one.

     Arnd