Re: [PATCH v2 1/7] dt-bindings: Add bindings for Azoteq IQS620A/621/622/624/625

[Rob Herring <robh@kernel.org>]

On Thu, Dec 19, 2019 at 9:00 PM Jeff LaBundy <jeff@labundy.com> wrote:
>
> Hi Rob,
>
> Thank you for your prompt review and your kind words. A couple of questions
> and comments for you below.
>
> On Wed, Dec 18, 2019 at 05:52:52PM -0600, Rob Herring wrote:
> > On Mon, Dec 09, 2019 at 12:38:32AM +0000, Jeff LaBundy wrote:
> > > This patch adds device tree bindings for the Azoteq IQS620A, IQS621,
> > > IQS622, IQS624 and IQS625 multi-function sensors.
> > >
> > > A total of three bindings are presented (one MFD and two child nodes);
> > > they are submitted as a single patch because the child node bindings
> > > have no meaning in the absence of the MFD binding.
> > >
> > > Signed-off-by: Jeff LaBundy <jeff@labundy.com>
> > > ---
> > > Changes in v2:
> > >   - Removed "prox" child node and moved "keys" and "pwm" child nodes to their
> > >     own bindings
> > >   - Replaced linux,fw-file property with more common firmware-name property
> > >   - Converted all bindings to YAML
> >
> > Good job for first go.
> >
> > >
> > >  .../devicetree/bindings/input/iqs62x-keys.yaml     | 126 +++++++++++++++
> > >  Documentation/devicetree/bindings/mfd/iqs62x.yaml  | 177 +++++++++++++++++++++
> > >  .../devicetree/bindings/pwm/iqs620a-pwm.yaml       |  30 ++++
> > >  3 files changed, 333 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/input/iqs62x-keys.yaml
> > >  create mode 100644 Documentation/devicetree/bindings/mfd/iqs62x.yaml
> > >  create mode 100644 Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml
> >
> > A couple of minor things below. With those fixed:
> >
> > Reviewed-by: Rob Herring <robh@kernel.org>
> >
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/iqs62x-keys.yaml b/Documentation/devicetree/bindings/input/iqs62x-keys.yaml
> > > new file mode 100644
> > > index 0000000..e9b54e0
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/iqs62x-keys.yaml
> > > @@ -0,0 +1,126 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/input/iqs62x-keys.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Azoteq IQS620A/621/622/624/625 Keys and Switches
> > > +
> > > +maintainers:
> > > +  - Jeff LaBundy <jeff@labundy.com>
> > > +
> > > +description: |
> > > +  The Azoteq IQS620A, IQS621, IQS622, IQS624 and IQS625 multi-function sensors
> > > +  feature a variety of self-capacitive, mutual-inductive and Hall-effect sens-
> > > +  ing capabilities that can facilitate a variety of contactless key and switch
> > > +  applications.
> > > +
> > > +  These functions are collectively represented by a "keys" child node from the
> > > +  parent MFD driver. See Documentation/devicetree/bindings/mfd/iqs62x.yaml for
> > > +  further details and examples. Sensor hardware configuration (self-capacitive
> > > +  vs. mutual-inductive, etc.) is selected based on the device's firmware.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - azoteq,iqs620a-keys
> > > +      - azoteq,iqs621-keys
> > > +      - azoteq,iqs622-keys
> > > +      - azoteq,iqs624-keys
> > > +      - azoteq,iqs625-keys
> > > +
> > > +  linux,keycodes:
> > > +    allOf:
> > > +      - $ref: /schemas/types.yaml#/definitions/uint32-array
> > > +      - minItems: 1
> > > +        maxItems: 16
> > > +    description: |
> > > +      Specifies the numeric keycodes associated with each available touch or
> > > +      proximity event according to the following table. An 'x' indicates the
> > > +      event is supported for a given device. Specify 0 for unused events.
> > > +
> > > +      -------------------------------------------------------------------------
> > > +      | #  | Event              | IQS620A | IQS621 | IQS622 | IQS624 | IQS625 |
> > > +      -------------------------------------------------------------------------
> > > +      | 0  | CH0 Touch          |    x    |    x   |    x   |    x   |    x   |
> > > +      |    | Antenna 1 Touch*   |    x    |        |        |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 1  | CH0 Proximity      |    x    |    x   |    x   |    x   |    x   |
> > > +      |    | Antenna 1 Prox.*   |    x    |        |        |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 2  | CH1 Touch          |    x    |    x   |    x   |    x   |    x   |
> > > +      |    | Ant. 1 Deep Touch* |    x    |        |        |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 3  | CH1 Proximity      |    x    |    x   |    x   |    x   |    x   |
> > > +      -------------------------------------------------------------------------
> > > +      | 4  | CH2 Touch          |    x    |        |        |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 5  | CH2 Proximity      |    x    |        |        |        |        |
> > > +      |    | Antenna 2 Prox.*   |    x    |        |        |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 6  | Metal (+) Touch**  |    x    |    x   |        |        |        |
> > > +      |    | Ant. 2 Deep Touch* |    x    |        |        |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 7  | Metal (+) Prox.**  |    x    |    x   |        |        |        |
> > > +      |    | Antenna 2 Touch*   |    x    |        |        |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 8  | Metal (-) Touch**  |    x    |    x   |        |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 9  | Metal (-) Prox.**  |    x    |    x   |        |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 10 | SAR Active***      |    x    |        |    x   |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 11 | SAR Quick Rel.***  |    x    |        |    x   |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 12 | SAR Movement***    |    x    |        |    x   |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 13 | SAR Filter Halt*** |    x    |        |    x   |        |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 14 | Wheel Up           |         |        |        |    x   |        |
> > > +      -------------------------------------------------------------------------
> > > +      | 15 | Wheel Down         |         |        |        |    x   |        |
> > > +      -------------------------------------------------------------------------
> > > +      *   Two-channel SAR. Replaces CH0-2 plus metal touch and proximity events
> > > +          if enabled via firmware.
> > > +      **  "+" and "-" refer to the polarity of a channel's delta (LTA - counts),
> > > +          where "LTA" is defined as the channel's long-term average.
> > > +      *** One-channel SAR. Replaces CH0-2 touch and proximity events if enabled
> > > +          via firmware.
> > > +
> > > +required:
> > > +  - compatible
> > > +  - linux,keycodes
> >
> > Add:
> >
> > additionalProperties: false
> >
>
> When I add this, the dt_binding_check step complains that the hall switch child nodes
> used in the examples are unrecognized, e.g.:
>
> iqs620a@44: keys: 'hall-switch-south' does not match any of the regexes: 'pinctrl-[0-9]+'
>
> When I originally encountered this, I found that the mdio-mux child node in [0] seems
> to be a similar example and omits additionalProperties, which is why I originally did
> that here. Do you have any advice on how to proceed?

That's because the properties are under an if/then. Your options are
split the schema into 2 files to eliminate the if/then or just define
"^hall-switch-(north|south)$" with just 'true' outside the if/then. A
variation on the 2nd option is invert the if/then and make the schema
false. Then the 'main' schema defines the full superset of properties
and the if/then just filters out ones that don't apply in some cases.

>
> > > +
> > > +if:
> > > +  properties:
> > > +    compatible:
> > > +      contains:
> > > +        enum:
> > > +          - azoteq,iqs620a-keys
> > > +          - azoteq,iqs621-keys
> > > +          - azoteq,iqs622-keys
> > > +then:
> > > +  patternProperties:
> > > +    "^hall-switch-(north|south)$":
> > > +      type: object
> > > +      description:
> > > +        Represents north/south-field Hall-effect sensor touch or proximity
> > > +        events. Note that north/south-field orientation is reversed on the
> > > +        IQS620AXzCSR device due to its flip-chip package.
> > > +
> > > +      properties:
> > > +        linux,code:
> > > +          $ref: /schemas/types.yaml#/definitions/uint32
> > > +          description: Numeric switch code associated with the event.
> > > +
> > > +        azoteq,use-prox:
> > > +          $ref: /schemas/types.yaml#/definitions/flag
> > > +          description:
> > > +            If present, specifies that Hall-effect sensor reporting should
> > > +            use the device's wide-range proximity threshold instead of its
> > > +            close-range touch threshold (default).
> > > +
> > > +      required:
> > > +        - linux,code
> > > +
>
> Do you think I should specify additionalProperties: false within these child nodes?

Yes.