linux-kernel - Re: [PATCH v2] Input: add 'safe' user switch codes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 5 Nov 2021 12:00:37 -0500
From:   Jeff LaBundy <jeff@...undy.com>
To:     Kieran Bingham <kieran.bingham+renesas@...asonboard.com>
Cc:     linux-input@...r.kernel.org, Geert Uytterhoeven <geert@...der.be>,
        linux-renesas-soc@...r.kernel.org,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Max Gurtovoy <mgurtovoy@...dia.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Wu Hao <hao.wu@...el.com>, Bjorn Helgaas <bhelgaas@...gle.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Dave Ertman <david.m.ertman@...el.com>,
        Maximilian Luz <luzmaximilian@...il.com>,
        Stephan Gerhold <stephan@...hold.net>,
        Xu Yilun <yilun.xu@...el.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Input: add 'safe' user switch codes

Hi Kieran,

On Fri, Nov 05, 2021 at 10:35:07AM +0000, Kieran Bingham wrote:
> All existing SW input codes define an action which can be interpreted by
> a user environment to adapt to the condition of the switch.
> 
> For example, switches to define the audio mute, will prevent audio
> playback, and switches to indicate lid and covers being closed may
> disable displays.
> 
> Many evaluation platforms provide switches which can be connected to the
> input system but associating these to an action incorrectly could
> provide inconsistent end user experiences due to unmarked switch
> positions.
> 
> Define two custom user defined switches allowing hardware descriptions
> to be created whereby the position of the switch is not interpreted as
> any standard condition that will affect a user experience.
> 
> This allows wiring up custom generic switches in a way that will allow
> them to be read and processed, without incurring undesired or otherwise
> undocumented (by the hardware) 'default' behaviours.
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@...asonboard.com>
> ---
> 
> Sigh, a compile test might have at least saved the buildbots the trouble
> of notifying me I also need to update the INPUT_DEVICE_ID_SW_MAX. But
> even so - I'm really looking for a discussion on the best ways to
> describe a non-defined switch in device tree.
> 
> Here's a compiling v2 ;-) But the real questions are :
> 
>  - Should an existing feature switch be used for generic switches?
>  - Should we even have a 'user' defined switch?
>  - If we add user switches, how many?
> 

This is merely my opinion, but if a hardware switch does not have a defined
purpose, it does not seem necessary to represent it with an input device.

If the goal is to simply perform validation of a driver and/or hardware, is
it not sufficient to map the switch to an existing code?

Similarly, there is no way to know if two are enough. What if we have a new
board tomorrow and need four?

> 
>  include/linux/mod_devicetable.h        | 2 +-
>  include/uapi/linux/input-event-codes.h | 4 +++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index ae2e75d15b21..dfa1e4f41cd8 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -326,7 +326,7 @@ struct pcmcia_device_id {
>  #define INPUT_DEVICE_ID_LED_MAX		0x0f
>  #define INPUT_DEVICE_ID_SND_MAX		0x07
>  #define INPUT_DEVICE_ID_FF_MAX		0x7f
> -#define INPUT_DEVICE_ID_SW_MAX		0x10
> +#define INPUT_DEVICE_ID_SW_MAX		0x12
>  #define INPUT_DEVICE_ID_PROP_MAX	0x1f
>  
>  #define INPUT_DEVICE_ID_MATCH_BUS	1
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 225ec87d4f22..84a7b3debcb3 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -894,7 +894,9 @@
>  #define SW_MUTE_DEVICE		0x0e  /* set = device disabled */
>  #define SW_PEN_INSERTED		0x0f  /* set = pen inserted */
>  #define SW_MACHINE_COVER	0x10  /* set = cover closed */
> -#define SW_MAX			0x10
> +#define SW_1			0x11  /* set = user defined */
> +#define SW_2			0x12  /* set = user defined */
> +#define SW_MAX			0x12
>  #define SW_CNT			(SW_MAX+1)
>  
>  /*
> -- 
> 2.30.2
> 

Kind regards,
Jeff LaBundy