Input: keypad-nomadik-ske - remove the driver
Subsystems (2)
Dmitry Torokhov
maintainerPATCH 1/1 Input: keypad-nomadik-ske - remove the driver
The users of this driver were removed in 2013 in commit 28633c54bda6 ("ARM: ux500: Rip out keypad initialisation which is no longer used").
Remove the driver as well.
--- drivers/input/keyboard/Kconfig | 11 - drivers/input/keyboard/Makefile | 1 - drivers/input/keyboard/nomadik-ske-keypad.c | 378 ------------------ .../linux/platform_data/keypad-nomadik-ske.h | 50 --- 4 files changed, 440 deletions(-)
drivers/input/keyboard/Kconfig +0 -11
@@ -473,17 +473,6 @@ config KEYBOARD_NEWTON To compile this driver as a module, choose M here: the module will be called newtonkbd. -config KEYBOARD_NOMADIK - tristate "ST-Ericsson Nomadik SKE keyboard" - depends on (ARCH_NOMADIK || ARCH_U8500 || COMPILE_TEST) - select INPUT_MATRIXKMAP - help - Say Y here if you want to use a keypad provided on the SKE controller - used on the Ux500 and Nomadik platforms - - To compile this driver as a module, choose M here: the - module will be called nmk-ske-keypad. - config KEYBOARD_NSPIRE tristate "TI-NSPIRE built-in keyboard" depends on ARCH_NSPIRE && OF
drivers/input/keyboard/Makefile +0 -1
@@ -45,7 +45,6 @@ obj-$(CONFIG_KEYBOARD_MPR121) += mpr121_touchkey.o obj-$(CONFIG_KEYBOARD_MT6779) += mt6779-keypad.o obj-$(CONFIG_KEYBOARD_MTK_PMIC) += mtk-pmic-keys.o obj-$(CONFIG_KEYBOARD_NEWTON) += newtonkbd.o -obj-$(CONFIG_KEYBOARD_NOMADIK) += nomadik-ske-keypad.o obj-$(CONFIG_KEYBOARD_NSPIRE) += nspire-keypad.o obj-$(CONFIG_KEYBOARD_OMAP) += omap-keypad.o obj-$(CONFIG_KEYBOARD_OMAP4) += omap4-keypad.o
drivers/input/keyboard/nomadik-ske-keypad.c deleted +0 -378
378 lines not on this page · raw message
include/linux/platform_data/keypad-nomadik-ske.h deleted +0 -50
50 lines not on this page · raw message
Signature · 5 lines
2.46.0.184.g6999bdac58-goog -- Dmitry
Quoted 5 lines · Dmitry Torokhov
The users of this driver were removed in 2013 in commit
28633c54bda6("ARM: ux500: Rip out keypad initialisation which is no longer used").Remove the driver as well.
Quoted 8 lines
Signed-off-by Dmitry Torokhov <[email protected]>--- drivers/input/keyboard/Kconfig | 11 - drivers/input/keyboard/Makefile | 1 - drivers/input/keyboard/nomadik-ske-keypad.c | 378 ------------------ .../linux/platform_data/keypad-nomadik-ske.h | 50 --- 4 files changed, 440 deletions(-)
I have a list of drivers that I determined to be likely unused as well and found a few more input drivers that were unused in 2022:
CONFIG_KEYBOARD_ADP5520/CONFIG_PMIC_ADP5520 CONFIG_KEYBOARD_ADP5589CONFIG_INPUT_AD714XCONFIG_TOUCHSCREEN_AD7877
As far as I can tell, these all lost their last device definition, or they never had one and are impossible to be used with device tree data.
Arnd
Dmitry Torokhov
maintainerQuoted 21 lines · Arnd Bergmann
Quoted 5 lines · Dmitry Torokhov
The users of this driver were removed in 2013 in commit
28633c54bda6("ARM: ux500: Rip out keypad initialisation which is no longer used").Remove the driver as well.
Quoted 8 lines
Signed-off-by Dmitry Torokhov <[email protected]>--- drivers/input/keyboard/Kconfig | 11 - drivers/input/keyboard/Makefile | 1 - drivers/input/keyboard/nomadik-ske-keypad.c | 378 ------------------ .../linux/platform_data/keypad-nomadik-ske.h | 50 --- 4 files changed, 440 deletions(-)Acked-by Arnd Bergmann <[email protected]>I have a list of drivers that I determined to be likely unused as well and found a few more input drivers that were unused in 2022:
Quoted 8 lines
CONFIG_KEYBOARD_ADP5520/CONFIG_PMIC_ADP5520
CONFIG_KEYBOARD_ADP5589CONFIG_INPUT_AD714XCONFIG_TOUCHSCREEN_AD7877As far as I can tell, these all lost their last device definition, or they never had one and are impossible to be used with device tree data.
I asked Analog Devices folks (CCed) about 5589 and Nuno said that it is still relevant and promised to do conversion to DT similar to adp5588.
Nuno, Michale, what about the other drivers that Arnd listed?
Thanks.
Signature · 1 line
Dmitry
Quoted 6 lines · Dmitry Torokhov
The users of this driver were removed in 2013 in commit
28633c54bda6("ARM: ux500: Rip out keypad initialisation which is no longer used").Remove the driver as well.
Signed-off-by Dmitry Torokhov <[email protected]>
This was intended for keypad phones based on ux500 and then the smartphone/touchscreen revolution happened and it was never used, it's there, but it's always dark silicon.
Yours,
Linus Walleij
Quoted 38 lines
-----Original Message-----
From: Dmitry Torokhov <[email protected]>
Sent: Monday, August 19, 2024 4:55 PM
To: Arnd Bergmann <[email protected]>; Nuno Sá <[email protected]>; Hennerich, Michael <[email protected]>
Cc: Linus Walleij <[email protected]>; [email protected]; linux- [email protected]; Lee Jones <[email protected]>; linux-arm- [email protected]; Agarwal, Utsav <[email protected]>
Subject: Re: [PATCH] Input: keypad-nomadik-ske - remove the driverQuoted 25 lines · Arnd Bergmann
Quoted 5 lines · Dmitry Torokhov
The users of this driver were removed in 2013 in commit
28633c54bda6("ARM: ux500: Rip out keypad initialisation which is no longer used").Remove the driver as well.
Quoted 8 lines
Signed-off-by Dmitry Torokhov <[email protected]>--- drivers/input/keyboard/Kconfig | 11 - drivers/input/keyboard/Makefile | 1 - drivers/input/keyboard/nomadik-ske-keypad.c | 378 ------------------ .../linux/platform_data/keypad-nomadik-ske.h | 50 --- 4 files changed, 440 deletions(-)Acked-by Arnd Bergmann <[email protected]>I have a list of drivers that I determined to be likely unused as well and found a few more input drivers that were unused in 2022:
CONFIG_KEYBOARD_ADP5520/CONFIG_PMIC_ADP5520
CONFIG_KEYBOARD_ADP5589CONFIG_INPUT_AD714XCONFIG_TOUCHSCREEN_AD7877
Quoted 8 lines
Quoted 3 lines
As far as I can tell, these all lost their last device definition, or they never had one and are impossible to be used with device tree data.
I asked Analog Devices folks (CCed) about 5589 and Nuno said that it is still relevant and promised to do conversion to DT similar to adp5588.
Nuno, Michale, what about the other drivers that Arnd listed?
We'll provide dt conversion patches for AD7877 and AD714x as well.
Regards,
Michael
Quoted 5 lines
Thanks.
--
Dmitry
Quoted 27 lines · Dmitry Torokhov
Quoted 26 lines · Arnd Bergmann
Quoted 5 lines · Dmitry Torokhov
The users of this driver were removed in 2013 in commit
28633c54bda6("ARM: ux500: Rip out keypad initialisation which is no longer used").Remove the driver as well.
Quoted 8 lines
Signed-off-by Dmitry Torokhov <[email protected]>---
drivers/input/keyboard/Kconfig | 11 - drivers/input/keyboard/Makefile | 1 - drivers/input/keyboard/nomadik-ske-keypad.c | 378 ------------------ .../linux/platform_data/keypad-nomadik-ske.h | 50 ---4 files changed, 440 deletions(-)Acked-by Arnd Bergmann <[email protected]>I have a list of drivers that I determined to be likely unused as well and found a few more input drivers that were unused in 2022:
CONFIG_KEYBOARD_ADP5520/CONFIG_PMIC_ADP5520
CONFIG_KEYBOARD_ADP5589CONFIG_INPUT_AD714XCONFIG_TOUCHSCREEN_AD7877
Quoted 9 lines
Quoted 3 lines
As far as I can tell, these all lost their last device definition, or they never had one and are impossible to be used with device tree data.
I asked Analog Devices folks (CCed) about 5589 and Nuno said that it is still relevant and promised to do conversion to DT similar to adp5588.
Nuno, Michale, what about the other drivers that Arnd listed?
Hi Dmitry,
This is not forgotten and I plan to start working on this early next week.
One thing I noticed and I might as well just ask before starting the work, is that the platform data allows, in theory, for you to have holes in your keymap [1]. Like enabling row 1 and 3 skipping 2. AFAICT, the matrix stuff does not allow this out of the box as we just define the number of rows/cols and then without any other property we assume (I think) that the map is contiguous.
This is just early thinking but one way to support the current behavior would be 2 custom DT properties that would be 2 u32 arrays specifying the enabled columns and rows. Out of it, we could build row and col masks and get the total number of cols and rows that we could pass to matrix_keypad_build_keymap().
The question is... is it worth it? I'm aware that if we just assume a contiguous keymap we could break some old users. But I guess it would be only out of tree ones as we don't have any in kernel user of the platform data. On top of it, I guess it's sane to assume that one just wants a contiguous keymap...
[1]: https://elixir.bootlin.com/linux/v6.10.8/source/drivers/input/keyboard/adp5589-keys.c#L630
Thanks!
- Nuno Sá
Dmitry Torokhov
maintainerHi Nuno,
Quoted 11 lines · Nuno Sá
Hi Dmitry,
This is not forgotten and I plan to start working on this early next week.
One thing I noticed and I might as well just ask before starting the work, is that the platform data allows, in theory, for you to have holes in your keymap [1]. Like enabling row 1 and 3 skipping 2. AFAICT, the matrix stuff does not allow this out of the box as we just define the number of rows/cols and then without any other property we assume (I think) that the map is contiguous.
Quoted 4 lines
This is just early thinking but one way to support the current behavior would be 2 custom DT properties that would be 2 u32 arrays specifying the enabled columns and rows. Out of it, we could build row and col masks and get the total number of cols and rows that we could pass to
matrix_keypad_build_keymap().
I'd ask DT maintainers but in my opinion we could add 2 u32 scalar properties to specify row and col masks (either enabled or disabled, whatever is more convenient) and then indeed we could figure out the resulting size of key matrix and use matrix_keypad_build_keymap() to load it.
Quoted 7 lines
The question is... is it worth it? I'm aware that if we just assume a contiguous keymap we could break some old users. But I guess it would be only out of tree ones as we don't have any in kernel user of the platform data. On top of it, I guess it's sane to assume that one just wants a contiguous keymap...
[1]: https://elixir.bootlin.com/linux/v6.10.8/source/drivers/input/keyboard/adp5589-keys.c#L630
I think in practice it's just a few extra lines of code, so shoudl be fairly easy to keep supporting this.
But we can actually split the binding and the driver implementation, with binding defining all capabilities of the hardware and driver implementing just a subset of it (i.e. complain if row and column mask properties are specified and abort probe).
Thanks.
Signature · 1 line
Dmitry
Quoted 26 lines · Dmitry Torokhov
Hi Nuno,
Quoted 15 lines · Nuno Sá
Hi Dmitry,
This is not forgotten and I plan to start working on this early next week.
One thing I noticed and I might as well just ask before starting the work, is that
the platform data allows, in theory, for you to have holes in your keymap [1]. Like
enabling row 1 and 3 skipping 2. AFAICT, the matrix stuff does not allow this out of
the box as we just define the number of rows/cols and then without any other property
we assume (I think) that the map is contiguous.Quoted 7 lines
This is just early thinking but one way to support the current behavior would be 2
custom DT properties that would be 2 u32 arrays specifying the enabled columns and
rows. Out of it, we could build row and col masks and get the total number of cols
and rows that we could pass tomatrix_keypad_build_keymap().
Quoted 6 lines
I'd ask DT maintainers but in my opinion we could add 2 u32 scalar properties to specify row and col masks (either enabled or disabled, whatever is more convenient) and then indeed we could figure out the resulting size of key matrix and use
matrix_keypad_build_keymap()to load it.
Alright, I'll see how it looks like and DT maintainers can then comment on it. I'm afraid they can complain about the masks (for not being super user friendly) but I think key arrays should be acceptable. I'll try the masks anyways...
- Nuno Sá