| Message ID | 20240805014710.1961677-1-dmitry.torokhov@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Remove support for platform data from matrix keypad driver | expand |
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.
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
On Mon, Aug 26, 2024, at 08:52, Linus Walleij wrote: > 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. Sorry I dropped the ball here, I just saw that these five patches are still in the patchwork waiting for me to apply them. I'm also happy for them to go through the input tree, and have marked them as not-for-us in patchwork now. Dmitry, please add my Acked-by: Arnd Bergmann <arnd@arndb.de> and pick them up in your tree. I've checked that there are no conflicts against contents of the SoC tree. If you prefer me to pick them up after all, that is also fine, but please resend in that case. Arnd
On Thu, Sep 05, 2024 at 02:36:15PM +0000, Arnd Bergmann wrote: > On Mon, Aug 26, 2024, at 08:52, Linus Walleij wrote: > > 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. > > Sorry I dropped the ball here, I just saw that these five patches > are still in the patchwork waiting for me to apply them. > > I'm also happy for them to go through the input tree, and have > marked them as not-for-us in patchwork now. Dmitry, please add > my > > Acked-by: Arnd Bergmann <arnd@arndb.de> > > and pick them up in your tree. I've checked that there are no > conflicts against contents of the SoC tree. If you prefer me to > pick them up after all, that is also fine, but please resend in > that case. I made an immutable branch off of 6.11-rc6 with the changesi and merged it into my 'next' branch for the upcoming merge window. Please feel free to also pull it - it does not have any unrelated changes: git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git ib/6.11-rc6-matrix-keypad-spitz Thanks.
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