Re: [PATCH v2 1/2] dt-bindings: input: Add bindings for Azoteq IQS7210A/7211A/E

[Jeff LaBundy <jeff@labundy.com>]

Hi Rob,

On Fri, Jun 09, 2023 at 08:25:38AM -0600, Rob Herring wrote:
> On Mon, May 29, 2023 at 07:33:47PM -0500, Jeff LaBundy wrote:
> > Add bindings for the Azoteq IQS7210A/7211A/E family of trackpad/
> > touchscreen controllers.
> > 
> > Signed-off-by: Jeff LaBundy <jeff@labundy.com>
> > ---
> > Changes in v2:
> >  - Renamed 'azoteq,default-comms' to 'azoteq,forced-comms-default' and redefined
> >    0, 1 and 2 as unspecified, 0 and 1, respectively
> >  - Defined ATI upon its first occurrence
> >  - Redefined 'azoteq,gesture-angle' in units of degrees
> >  - Declared 'azoteq,rx-enable' to depend upon 'azoteq,tx-enable' within the
> >    'trackpad' node
> > 
> > Hi Rob,
> > 
> > I attempted to reference existing properties from a common binding [1] as per
> > your feedback in [2], however 'make DT_CHECKER_FLAGS=-m dt_binding_check' fails
> > with the message 'Vendor specific properties must have a type and description
> > unless they have a defined, common suffix.'
> 
> Is that because you have differing constraints in each case?

In the failing example [2], I have started with a simple boolean that carries
nothing but a type and description. From the new azoteq,common.yaml:

properties:
  [...]

  azoteq,use-prox:
    type: boolean
    description: foo

And from the first consumer:

patternProperties:
  "^hall-switch-(north|south)$":
    type: object
    allOf:
      - $ref: input.yaml#
      - $ref: azoteq,common.yaml#
    description: bar

    properties:
      linux,code: true
      azoteq,use-prox: true

However, the tooling presents the following:

  CHKDT   Documentation/devicetree/bindings/processed-schema.json
/home/jlabundy/work/linux/Documentation/devicetree/bindings/input/iqs62x-keys.yaml: patternProperties:^hall-switch-(north|south)$:properties:azoteq,use-prox: True is not of type 'object'
	hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
	from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#

[...]

I am committed to addressing your feedback; to help me do so, can you help me
identify what I've done wrong, and/or point me to an example that successfully
passes dt_binding_check?

> 
> > This seems related to the discussion in [3], where you warned that the tooling
> > cannot yet deduce that vendor-specific properties have already been typed in an
> > externally $ref'd binding. The only other example of a common vendor schema is
> > [4], but in that case the common properties are defined under arbitraily named
> > pinmux config nodes. As such, they are part of 'additionalProperties' instead of
> > 'properties' and hence exempt from this particular validation.
> > 
> > Please let me know if I am mistaken (surprise!), in which case I will continue
> > on this path and send a v3. Otherwise, I would like to suggest that the review
> > moves forward under the premise that I will happily consolidate these bindings
> > once the tooling supports this idea.
> > 
> > Kind regards,
> > Jeff LaBundy

[2] https://github.com/jlabundy/linux/tree/azoteq-common

Kind regards,
Jeff LaBundy