From: Rob Herring <robh@kernel.org>
To: Jeff LaBundy <jeff@labundy.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: input: Add bindings for Azoteq IQS7210A/7211A/E
Date: Mon, 12 Jun 2023 09:29:25 -0600 [thread overview]
Message-ID: <20230612152925.GA65549-robh@kernel.org> (raw)
In-Reply-To: <ZIZvkGqr4a0kOGnR@nixie71>
On Sun, Jun 11, 2023 at 08:06:24PM -0500, Jeff LaBundy wrote:
> 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?
You're not doing anything wrong. There's 2 options here. The first is we
could just relax the check to allow boolean schema for vendor
properties. The main issue with that is we then have to look for that
improperly used and it doesn't help if you do have additional
constraints to add on top of the common definition. The former can
mostly be addressed by checking there is a type associated with the
property. I'm going to look into adding that.
Alternatively, you could drop listing the properties and
use 'unevaluatedProperties'. That's not quite equal to what you have.
Presumably, you have 'additionalProperties' in this case, so listing
them serves the purpose of defining what subset of properties each node
uses from the referenced schema. We frequently don't worry if there are
common properties not used by a specific schema. This also wouldn't work
if you have additional constraints to add.
Rob
next prev parent reply other threads:[~2023-06-12 15:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 0:31 [PATCH v2 0/2] Add support for Azoteq IQS7210A/7211A/E Jeff LaBundy
2023-05-30 0:33 ` [PATCH v2 1/2] dt-bindings: input: Add bindings " Jeff LaBundy
2023-06-09 14:25 ` Rob Herring
2023-06-12 1:06 ` Jeff LaBundy
2023-06-12 15:29 ` Rob Herring [this message]
2023-06-13 0:58 ` Jeff LaBundy
2023-06-14 18:51 ` Rob Herring
2023-06-14 18:52 ` Rob Herring
2023-05-30 0:34 ` [PATCH v2 2/2] Input: add support " Jeff LaBundy
2023-07-12 21:26 ` [PATCH v2 0/2] Add " Jeff LaBundy
2023-07-12 21:34 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230612152925.GA65549-robh@kernel.org \
--to=robh@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=jeff@labundy.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-input@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).