Hi,

This series attempts to remove support for platform data from
matrix_keypad driver, and have it use generic device properties only
for the keypad configuration. Spitz is the only board [left] that
uses platform data.

As part of the migration I am also dropping support for "clustered"
interrupt mode, as it was only available through platform data and there
are no users of it in the mainline kernel.

Additionally gpio-keys device used by Spitz converted to use device
properties instead of platform data.  

I would prefer not to have the song and dance of merging first 2 patches
through the input tree, waiting, merging the spitz patches through SoC
tree, waiting, and finally merging the last patch to matrix keypad
through input again, so maybe we could merge it all through SoC?
Alternatively, I could merge everything through input. What do you
think?

Dmitry Torokhov (5):
  Input: matrix_keypad - remove support for clustered interrupt
  Input: matrix_keypad - switch to gpiod API and generic device
    properties
  ARM: spitz: Use software nodes/properties for the GPIO-driven buttons
  ARM: spitz: Use software nodes/properties for the matrix keypad
  Input: matrix_keypad - remove support for platform data

 arch/arm/mach-pxa/spitz.c              | 163 ++++++++----
 drivers/input/keyboard/matrix_keypad.c | 334 ++++++++++---------------
 include/linux/input/matrix_keypad.h    |  48 ----
 3 files changed, 248 insertions(+), 297 deletions(-)

Thanks.

--
Dmitry

On Mon, Aug 5, 2024 at 3:47 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

> This series attempts to remove support for platform data from
> matrix_keypad driver, and have it use generic device properties only
> for the keypad configuration. Spitz is the only board [left] that
> uses platform data.
>
> As part of the migration I am also dropping support for "clustered"
> interrupt mode, as it was only available through platform data and there
> are no users of it in the mainline kernel.
>
> Additionally gpio-keys device used by Spitz converted to use device
> properties instead of platform data.
>
> I would prefer not to have the song and dance of merging first 2 patches
> through the input tree, waiting, merging the spitz patches through SoC
> tree, waiting, and finally merging the last patch to matrix keypad
> through input again, so maybe we could merge it all through SoC?
> Alternatively, I could merge everything through input. What do you
> think?

Sounds like a plan. The series:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Hi Linus,

On Fri, Aug 23, 2024 at 05:51:30PM +0200, Linus Walleij wrote:
> On Mon, Aug 5, 2024 at 3:47 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> 
> > This series attempts to remove support for platform data from
> > matrix_keypad driver, and have it use generic device properties only
> > for the keypad configuration. Spitz is the only board [left] that
> > uses platform data.
> >
> > As part of the migration I am also dropping support for "clustered"
> > interrupt mode, as it was only available through platform data and there
> > are no users of it in the mainline kernel.
> >
> > Additionally gpio-keys device used by Spitz converted to use device
> > properties instead of platform data.
> >
> > I would prefer not to have the song and dance of merging first 2 patches
> > through the input tree, waiting, merging the spitz patches through SoC
> > tree, waiting, and finally merging the last patch to matrix keypad
> > through input again, so maybe we could merge it all through SoC?
> > Alternatively, I could merge everything through input. What do you
> > think?
> 
> Sounds like a plan. The series:
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Thanks!

I'm glad that we agree that we do not want the elaborate merge process
and instead push the changes through one tree in one shot we just need
to decide which one - soc or input. I am fine with using either.

Sorry if I am being obtuse.

Thanks.

-- 
Dmitry

On Fri, Aug 23, 2024 at 6:02 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

> I'm glad that we agree that we do not want the elaborate merge process
> and instead push the changes through one tree in one shot we just need
> to decide which one - soc or input. I am fine with using either.

I'm also fine with either, but let's take the input tree because the
you're in direct control of it so it will be easier.

Yours,
Linus Walleij