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  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:   Wed, 6 Jan 2021 18:21:58 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Stephen Boyd <swboyd@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Benson Leung <bleung@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        Guenter Roeck <groeck@...omium.org>
Subject: Re: [PATCH] Input: cros_ec_keyb: Add support for a front proximity
 switch

Hi Doug, Stephen,

On Wed, Jan 06, 2021 at 05:16:10PM -0800, Doug Anderson wrote:
> Hi,
> 
> On Fri, Dec 4, 2020 at 4:48 PM Stephen Boyd <swboyd@...omium.org> wrote:
> >
> > Some cros ECs support a front proximity MKBP event via
> > 'EC_MKBP_FRONT_PROXIMITY'. Map this to the 'SW_FRONT_PROXIMITY' input
> > event code so it can be reported up to userspace.
> >
> > Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>
> > Cc: Benson Leung <bleung@...omium.org>
> > Cc: Guenter Roeck <groeck@...omium.org>
> > Signed-off-by: Stephen Boyd <swboyd@...omium.org>
> > ---
> >  drivers/input/keyboard/cros_ec_keyb.c          | 5 +++++
> >  include/linux/platform_data/cros_ec_commands.h | 1 +
> >  2 files changed, 6 insertions(+)
> 
> This seems really straightforward.
> 
> Reviewed-by: Douglas Anderson <dianders@...omium.org>
> 
> Given that it touches a header file owned by the Chrome OS maintainers
> and a driver owned by input, how should it land?  One maintainer Acks
> and the other lands?

Sorry about missing this one, however the "front proximity" switch has
been introduced for the benefit of phone devices, to be emitted when a
device is raised to user's ear, and I do not think we should be using
this here.

We have just recently had similar discussion with regard to palm- and
lap-mode sensors and whether they should be reported over input or IIO
as true proximity sensors:

https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/

Based on what we are doing for other Chrome OS devices that expose
proximity sensors (for example trogdor) we have decided that we all
should be using IIO as it will allow not only on/off, but true proximity
reporting with potential of implementing smarter policies by userspace.

Because of that we should do the same here and export this as IIO
proximity sensor as well.

Thanks.

-- 
Dmitry

Powered by blists - more mailing lists