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@xxxxxxxxxxx> 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@xxxxxxxxxxx> > > > > --- > > > > 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@xxxxxxxxxx> > > > > > > > > > > > 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@xxxxxxxxxxx> > > > > + > > > > +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
