linux-kernel - Re: [PATCH v2 1/2] dt-bindings: google,cros-ec-keyb: Introduce switches only compatible

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:   Mon, 2 May 2022 16:49:39 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Doug Anderson <dianders@...omium.org>
Cc:     LKML <linux-kernel@...r.kernel.org>, patches@...ts.linux.dev,
        chrome-platform@...ts.linux.dev,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Benson Leung <bleung@...omium.org>,
        Guenter Roeck <groeck@...omium.org>,
        Hsin-Yi Wang <hsinyi@...omium.org>,
        "Joseph S. Barrera III" <joebar@...omium.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: google,cros-ec-keyb: Introduce
 switches only compatible

Quoting Stephen Boyd (2022-05-02 13:41:33)
> Quoting Dmitry Torokhov (2022-05-02 10:43:06)
>
> > We have
> > implemented the notion that without rows/columns properties we will
> > not be creating input device for the matrix portion, all older devices
> > should have it defined, so the newer driver is compatible with them...
> >
>
> Agreed, that solves half the problem. This new compatible eases
> integration so that devicetrees can say they're compatible with the old
> binding that _requires_ the rows/column properties. By making the driver
> change we loosened that requirement, but the binding should have been
> making the properties required at the start because it fails to bind
> otherwise.
>
> My interpretation of what Doug is saying is that we should maintain that
> requirement that rows/columns exists if the original compatible
> google,cros-ec-keyb is present and use the new compatible to indicate
> that there are switches. Combining the two compatibles means there's
> switches and a matrix keyboard, having only the switches compatible
> means only switches, and having only the keyboard compatible means only
> matrix keyboard.
>
> It sounds OK to me.

There's one more thing to mention. The switches are discovered by
querying the EC. Reverting commit 4352e23a7ff2 ("Input: cros-ec-keyb -
only register keyboard if rows/columns exist") makes it so that in the
case you have a keyboard and switches you'll be tempted to define both
compatibles because you have some switches, but for all practical
purposes you don't need to change anything. The EC will still be queried
for the switches. Maybe "google,cros-ec-keyb-switches" is a bad name. It
should really be "google,cros-ec-keyb-v2" or
"google,cros-ec-keyb-optional" where we clarify that matrix keyboard
properties are optional now and are used to indicate if there's a matrix
keyboard or not.