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