* Add the gpio number, so the button subsystem can find the right gpio.
* Change also the keycode from KEY_SETUP to KEY_RESTART, because it
seems more expressive to me and in the Alix-Board, which is the
predecessor, there isthis keycode defined too. I think this is also
intended by Pcengines. Also many embedded systems defined in the kernel
use this key code as well.
Signed-off-by: Florian Eckert <[email protected]>
---
drivers/platform/x86/pcengines-apuv2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/pcengines-apuv2.c b/drivers/platform/x86/pcengines-apuv2.c
index d50a50e9d34c..370fd2686d59 100644
--- a/drivers/platform/x86/pcengines-apuv2.c
+++ b/drivers/platform/x86/pcengines-apuv2.c
@@ -116,7 +116,8 @@ struct gpiod_lookup_table gpios_led_table = {
static struct gpio_keys_button apu2_keys_buttons[] = {
{
- .code = KEY_SETUP,
+ .code = KEY_RESTART,
+ .gpio = 508,
.active_low = 1,
.desc = "front button",
.type = EV_KEY,
--
2.11.0
On 04.07.19 11:02, Florian Eckert wrote:
> * Add the gpio number, so the button subsystem can find the right gpio.
> * Change also the keycode from KEY_SETUP to KEY_RESTART, because it
> seems more expressive to me and in the Alix-Board, which is the
> predecessor, there isthis keycode defined too. I think this is also
> intended by Pcengines. Also many embedded systems defined in the kernel
> use this key code as well.
In general, I'm not opposed to that, but I'll first have to check trough
various userland code to make sure that it doesn't break
anything in the field, before I can give my ack.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287
On 04.07.19 11:02, Florian Eckert wrote:
> * Add the gpio number, so the button subsystem can find the right gpio.
> * Change also the keycode from KEY_SETUP to KEY_RESTART, because it
> seems more expressive to me and in the Alix-Board, which is the
> predecessor, there isthis keycode defined too. I think this is also
> intended by Pcengines. Also many embedded systems defined in the kernel
> use this key code as well.
>
> Signed-off-by: Florian Eckert <[email protected]>
> ---
> drivers/platform/x86/pcengines-apuv2.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/pcengines-apuv2.c b/drivers/platform/x86/pcengines-apuv2.c
> index d50a50e9d34c..370fd2686d59 100644
> --- a/drivers/platform/x86/pcengines-apuv2.c
> +++ b/drivers/platform/x86/pcengines-apuv2.c
> @@ -116,7 +116,8 @@ struct gpiod_lookup_table gpios_led_table = {
>
> static struct gpio_keys_button apu2_keys_buttons[] = {
> {
> - .code = KEY_SETUP,
> + .code = KEY_RESTART,
> + .gpio = 508,
> .active_low = 1,
> .desc = "front button",
> .type = EV_KEY,
>
I'd like to ack only the keycode change, but not the deprecated .gpio
field. I'll post a separate patch for the keycode change only.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287
> I'd like to ack only the keycode change, but not the deprecated .gpio
> field. I'll post a separate patch for the keycode change only.
I am fine if we only change the keycode.
Do I have to send a v2 patch set?
On 23.07.19 09:06, Florian Eckert wrote:
>> I'd like to ack only the keycode change, but not the deprecated .gpio
>> field. I'll post a separate patch for the keycode change only.
>
> I am fine if we only change the keycode.
> Do I have to send a v2 patch set?
>
already sent one.
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287