[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYFc8vuz__7DkFSMFxUC=LSwCJmEun2KXgUvPMq+_e17A@mail.gmail.com>
Date: Fri, 23 Aug 2024 17:51:30 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Haojian Zhuang <haojian.zhuang@...il.com>, Daniel Mack <daniel@...que.org>,
Robert Jarzmik <robert.jarzmik@...e.fr>, Arnd Bergmann <arnd@...db.de>, soc@...nel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-input@...r.kernel.org
Subject: Re: [PATCH 0/5] Remove support for platform data from matrix keypad driver
On Mon, Aug 5, 2024 at 3:47 AM Dmitry Torokhov
<dmitry.torokhov@...il.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@...aro.org>
Yours,
Linus Walleij
Powered by blists - more mailing lists