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>] [day] [month] [year] [list]
Message-ID: <161075063876.3661239.2601657304680031525@swboyd.mtv.corp.google.com>
Date:   Fri, 15 Jan 2021 14:43:58 -0800
From:   Stephen Boyd <swboyd@...omium.org>
To:     Doug Anderson <dianders@...omium.org>,
        Guenter Roeck <groeck@...gle.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        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

Quoting Guenter Roeck (2021-01-06 18:30:20)
> On Wed, Jan 6, 2021 at 5:16 PM Doug Anderson <dianders@...omium.org> 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 +
> 
> 
> For a year or two people kept changes to cros_ec_commands.h separate from
> functional changes. Unfortunately, we are now reverting to the old
> "change cros_ec_commands.h together with some functional change" approach which
> caused an endless amount of trouble and pain for Chrome OS rebases a couple of
> years ago.
> 
> I won't NACK this patch, but it is close.

I'm fine to split it into two, or keep it together. Just let me know
what is preferred. Thanks!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ