[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <161058782774.3661239.6435895454078235399@swboyd.mtv.corp.google.com>
Date: Wed, 13 Jan 2021 17:30:27 -0800
From: Stephen Boyd <swboyd@...omium.org>
To: LKML <linux-kernel@...r.kernel.org>,
Philip Chen <philipchen@...omium.org>,
dmitry.torokhov@...il.com
Cc: dianders@...omium.org, Philip Chen <philipchen@...omium.org>,
Benson Leung <bleung@...omium.org>,
Enric Balletbo i Serra <enric.balletbo@...labora.com>,
Guenter Roeck <groeck@...omium.org>,
Rob Herring <robh+dt@...nel.org>,
Simon Glass <sjg@...omium.org>, devicetree@...r.kernel.org,
linux-input@...r.kernel.org
Subject: Re: [PATCH v5 1/2] dt-bindings: input: cros-ec-keyb: Add a new property
Quoting Philip Chen (2021-01-13 17:25:12)
> This patch adds a new property `function-row-physmap` to the
:)
> device tree for the custom keyboard top row design.
>
> The property describes the rows/columns of the top row keys
> from left to right.
>
> Signed-off-by: Philip Chen <philipchen@...omium.org>
> ---
>
> Changes in v5:
> - add minItems and maxItems for `function-row-physmap`
>
> Changes in v2:
> - add `function-row-physmap` instead of `google,custom-keyb-top-row`
>
> .../bindings/input/google,cros-ec-keyb.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml
> index 8e50c14a9d778..e573ef3e58b65 100644
> --- a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml
> +++ b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml
> @@ -31,6 +31,18 @@ properties:
> if the EC does not have its own logic or hardware for this.
> type: boolean
>
> + function-row-physmap:
> + $ref: '/schemas/types.yaml#/definitions/uint32-array'
I'm not sure this is needed if min/max items is there.
> + minItems: 1
> + maxItems: 15
> + description: |
> + An ordered u32 array describing the rows/columns (in the scan matrix)
> + of top row keys from physical left (KEY_F1) to right. Each entry
> + encodes the row/column as:
> + (((row) & 0xFF) << 24) | (((column) & 0xFF) << 16)
> + where the lower 16 bits are reserved. This property is specified only
> + when the keyboard has a custom design for the top row keys.
Can you add it to the example so it can be tested? Then you can prove
out if the ref is needed or not.
> +
> required:
> - compatible
>
Powered by blists - more mailing lists