On 08/06/2022 23:20, Rob Herring wrote: > On Sun, Jun 5, 2022 at 9:15 AM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> >> On 03/06/2022 18:43, Dmitry Torokhov wrote: >>> On Fri, Jun 03, 2022 at 12:16:01PM +0200, Krzysztof Kozlowski wrote: >>>> The original text bindings documented "autorepeat" and "label" >>>> properties (in the device node, beside the nodes with keys). >>>> >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> >>>> --- >>>> Documentation/devicetree/bindings/input/gpio-keys.yaml | 8 ++++++++ >>>> 1 file changed, 8 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/input/gpio-keys.yaml b/Documentation/devicetree/bindings/input/gpio-keys.yaml >>>> index 49d388dc8d78..b1c910a5e233 100644 >>>> --- a/Documentation/devicetree/bindings/input/gpio-keys.yaml >>>> +++ b/Documentation/devicetree/bindings/input/gpio-keys.yaml >>>> @@ -15,6 +15,14 @@ properties: >>>> - gpio-keys >>>> - gpio-keys-polled >>>> >>>> + autorepeat: >>>> + type: boolean >>>> + description: >>>> + Enable operating system (not hardware) key auto repeat feature. >>> >>> Should we refer to the generic input device property here instead (one >>> on described in input.yaml)? >> >> You mean copy the description from input.yaml or say something like: >> "see input.yaml"? > > No, just: > > $ref: input.yaml# > properties: > autorepeat: true > > And 'poll-interval' needs its definition removed. > > It's a bit strange for input.yaml to be referenced in both the parent > and child nodes, but that's the nature of the input bindings. Maybe > input.yaml could be split? Doesn't really look like it to me. The main > issue with one file is the users need to list out which properties > they use (not a bad thing). > > Note that this series (patch 1) is going to conflict with what I just > sent out[1]. I can rebase on top of it. I understand that idea of the series looks good, so I will work on DTSes and v2 of this. Best regards, Krzysztof
