[RFC] Input: matrix_keypad: fix interrupt regression introduced by commit 01c84b03d80a

[Alexander Kochetkov]

Hi everyone,

I found a commit [1] that breaks the matrix_keypad behavior on the Allwinner A64.

I have a PINE A64-LTS board with a connected keypad polled by matrix_keypad.
This commit caused interrupts to stop arriving at the matrix_keypad driver entirely.

An explicit call to gpiod_direction_input() disables interrupt reception on all chips
where the GPIO input mode and GPIO interrupt input mode are configured via
the pinmux register. Interrupt reception is guaranteed to break on Allwinner
(A64, H3, H6, etc.), Broadcom (BCM2835/2711), and some Rockchip SoCs. It
does not break on NXP i.MX (i.MX6, i.MX8), STMicroelectronics (STM32MP1),
TI Sitara (AM335x), or Intel/AMD.

Furthermore, the assumption that enable_row_irqs() restores the interrupt mode is
also specific to the Ingenic pinctrl. In the vast majority of drivers, enable_row_irqs() is
supposed to simply set the interrupt enable mask without changing the pinmux.

Commit [1] was introduced to work around a hardware limitation in Ingenic's JZ4755.
This specific behavior is unique to Ingenic and a small number of specialized chips.
The majority of SoCs (around 90%) allow reading a GPIO input that is currently configured
as an interrupt source.

In my opinion, the correct approach would be to revert this commit and fix the behavior of
ingenic_gpio_get_value() inside pinctrl-ingenic.c instead. However, I do not own an Ingenic
board, so I won't be able to test such a patch.

Alternatively, I could introduce a DTS property like read-gpio-quirk in matrix_keypad to restore
the original driver behavior by default, and add this property to qi_lb60.dts so as not to break
the Ingenic platform.

What do you think? What is the best way to proceed here?

Best regards,
Alexander Kochetkov

[1] commit 01c84b03d80aab9f04c4e3e1f9085f4202ff7c29 ("Input: matrix_keypad - force switch rows to input mode")