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

Jeff LaBundy
2020-01-01T21:32:50Z

Hi Rob,

On Tue, Dec 24, 2019 at 02:55:41PM -0700, Rob Herring wrote:
> 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.
>

Thank you for this detailed explanation; it all makes sense now. For v3
I've opted for the variant of option (2) because it allows for a single
binding as I originally intended, and prompts dt_binding_check to throw
an error if a dts author mistakenly defines the hall-switch-north/south
nodes within either of the two devices that don't support that feature.
I also find it simpler and more intuitive.

> >
> > > > +
> > > > +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.

Sure thing, will do.

FYI, since these additional changes are quite small and I believe I've
implemented them exactly as you've suggested, I plan on retaining your
Reviewed-by for v3 which I'll be sending out soon. However if you find
that I have misinterpreted anything, please let me know and I will fix
it promptly.

Wishing you a Happy New Year,
Jeff LaBundy