devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: Jon Hunter <jonathanh@nvidia.com>,
	devicetree@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH v2 13/16] dt-bindings: i2c: tegra-bpmp: Convert to json-schema
Date: Thu, 2 Dec 2021 18:55:04 +0100	[thread overview]
Message-ID: <YakIePafm3t6rJLE@orome.fritz.box> (raw)
In-Reply-To: <CAL_Jsq+JvZQjN3q4A3yoM+pUPHLYKtwUT=QsDq+oQ7jk8mD3CA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 7792 bytes --]

On Wed, Dec 01, 2021 at 12:42:07PM -0600, Rob Herring wrote:
> On Wed, Dec 1, 2021 at 11:42 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Mon, Nov 29, 2021 at 07:44:32PM -0600, Rob Herring wrote:
> > > On Fri, Nov 19, 2021 at 03:38:36PM +0100, Thierry Reding wrote:
> > > > From: Thierry Reding <treding@nvidia.com>
> > > >
> > > > Convert the NVIDIA Tegra186 (and later) BPMP I2C bindings from the
> > > > free-form text format to json-schema.
> > > >
> > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > > ---
> > > > Changes in v2:
> > > > - add missing additionalProperties: false
> > > >
> > > >  .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt | 42 -------------------
> > > >  .../i2c/nvidia,tegra186-bpmp-i2c.yaml         | 42 +++++++++++++++++++
> > > >  2 files changed, 42 insertions(+), 42 deletions(-)
> > > >  delete mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
> > > >  create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
> > > > deleted file mode 100644
> > > > index ab240e10debc..000000000000
> > > > --- a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
> > > > +++ /dev/null
> > > > @@ -1,42 +0,0 @@
> > > > -NVIDIA Tegra186 BPMP I2C controller
> > > > -
> > > > -In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW
> > > > -devices, such as the I2C controller for the power management I2C bus. Software
> > > > -running on other CPUs must perform IPC to the BPMP in order to execute
> > > > -transactions on that I2C bus. This binding describes an I2C bus that is
> > > > -accessed in such a fashion.
> > > > -
> > > > -The BPMP I2C node must be located directly inside the main BPMP node. See
> > > > -../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding.
> > > > -
> > > > -This node represents an I2C controller. See ../i2c/i2c.txt for details of the
> > > > -core I2C binding.
> > > > -
> > > > -Required properties:
> > > > -- compatible:
> > > > -    Array of strings.
> > > > -    One of:
> > > > -    - "nvidia,tegra186-bpmp-i2c".
> > > > -- #address-cells: Address cells for I2C device address.
> > > > -    Single-cell integer.
> > > > -    Must be <1>.
> > > > -- #size-cells:
> > > > -    Single-cell integer.
> > > > -    Must be <0>.
> > > > -- nvidia,bpmp-bus-id:
> > > > -    Single-cell integer.
> > > > -    Indicates the I2C bus number this DT node represent, as defined by the
> > > > -    BPMP firmware.
> > > > -
> > > > -Example:
> > > > -
> > > > -bpmp {
> > > > -   ...
> > > > -
> > > > -   i2c {
> > > > -           compatible = "nvidia,tegra186-bpmp-i2c";
> > > > -           #address-cells = <1>;
> > > > -           #size-cells = <0>;
> > > > -           nvidia,bpmp-bus-id = <5>;
> > > > -   };
> > > > -};
> > > > diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml
> > > > new file mode 100644
> > > > index 000000000000..351e12124959
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml
> > > > @@ -0,0 +1,42 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/i2c/nvidia,tegra186-bpmp-i2c.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: NVIDIA Tegra186 (and later) BPMP I2C controller
> > > > +
> > > > +maintainers:
> > > > +  - Thierry Reding <thierry.reding@gmail.com>
> > > > +  - Jon Hunter <jonathanh@nvidia.com>
> > > > +
> > > > +description: |
> > > > +  In Tegra186 and later, the BPMP (Boot and Power Management Processor)
> > > > +  owns certain HW devices, such as the I2C controller for the power
> > > > +  management I2C bus. Software running on other CPUs must perform IPC to
> > > > +  the BPMP in order to execute transactions on that I2C bus. This
> > > > +  binding describes an I2C bus that is accessed in such a fashion.
> > > > +
> > > > +  The BPMP I2C node must be located directly inside the main BPMP node.
> > > > +  See ../firmware/nvidia,tegra186-bpmp.yaml for details of the BPMP
> > > > +  binding.
> > > > +
> > > > +  This node represents an I2C controller. See ../i2c/i2c.txt for details
> > > > +  of the core I2C binding.
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    const: nvidia,tegra186-bpmp-i2c
> > > > +
> > >
> > > > +  "#address-cells":
> > > > +    const: 1
> > > > +
> > > > +  "#size-cells":
> > > > +    const: 0
> > >
> > > Covered by i2c-controller.yaml. Add a reference and then use
> > > unevaluatedProperties.
> >
> > About that: I've recently noticed that this doesn't seem to work
> > properly. I'm using branch draft2020-12 from your github and my
> 
> Use dtschema main/master branch. That branch is likely stale.

That seems to have helped somewhat. I do occasionally see warnings now
about unevaluated properties being unexpected. I can still reproduce the
issue, though, see below.

> > understanding was that this should give us support for
> > unevaluatedProperties. And indeed, it no longer complains about
> > #address-cells and #size-cells if I remove them from this binding,
> > presumably because it gets them from i2c-controller.yaml.
> >
> > However, a side-effect seems to be that now it also ignores any
> > properties that aren't defined anywhere. So for example if I touch
> > up the example in firmware/nvidia,tegra186-bpmp.yaml and add a bogus
> > "foo-bar = <0>;" property in the BPMP I2C node, then it'll blindly
> > accept that as valid.
> 
> Do you have unevaluatedProperties within the i2c node? It only applies
> to 1 level, and you can't have a parent+child schema evaluated with
> another child (or parent+child) schema. This is why the graph schema
> is done the way it is and why we're splitting spi-controller.yaml
> child node schema out to spi-peripheral.yaml.

Let me give an example based on a schema that's already upstream. So
looking at this:

	Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml

it does include spi-controller.yaml via an allOf: [ $ref: ... ], so it
uses unevaluatedProperties to validate against any generic SPI
controller properties. For example, #address-cells and #size-cells are
validated based on the schema from spi-controller.yaml.

However, if I now apply the following patch to add an undocumented
property to the example, then validation doesn't fail as I would expect
it to.

--- >8 ---
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
index 35a8045b2c70..e9342faf5194 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
@@ -104,6 +104,7 @@ examples:
             resets = <&tegra_car 211>;
             dmas = <&apbdma 5>, <&apbdma 5>;
             dma-names = "rx", "tx";
+            foo-something = <42>;
 
             flash@0 {
                     compatible = "spi-nor";
--- >8 ---

I would expect the validation to fail for foo-something because it isn't
defined in any of the schemas.

Or is this one of the cases that you mentioned above. I must admit I did
not follow what exactly is expected to work and what isn't. The QSPI
controller example from above seems simple enough.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-12-02 17:55 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19 14:38 [PATCH v2 00/16] dt-bindings: Convert Tegra DT bindings to json-schema Thierry Reding
2021-11-19 14:38 ` [PATCH v2 01/16] dt-bindings: misc: Convert Tegra MISC " Thierry Reding
2021-11-30  1:29   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 02/16] dt-bindings: mmc: tegra: Convert " Thierry Reding
2021-11-30  1:31   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 03/16] dt-bindings: mailbox: " Thierry Reding
2021-11-30  1:32   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 04/16] dt-bindings: mailbox: tegra: Document Tegra234 HSP Thierry Reding
2021-11-30  1:32   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 05/16] dt-bindings: rtc: tegra: Convert to json-schema Thierry Reding
2021-11-30  1:33   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 06/16] dt-bindings: rtc: tegra: Document Tegra234 RTC Thierry Reding
2021-11-30  1:33   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 07/16] dt-bindings: fuse: tegra: Convert to json-schema Thierry Reding
2021-11-30  1:35   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 08/16] dt-bindings: fuse: tegra: Document Tegra234 FUSE Thierry Reding
2021-11-30  1:35   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 09/16] dt-bindings: mmc: tegra: Document Tegra234 SDHCI Thierry Reding
2021-11-30  1:35   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 10/16] dt-bindings: serial: 8250: Document Tegra234 UART Thierry Reding
2021-11-30  1:36   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 11/16] dt-bindings: tegra: pmc: Convert to json-schema Thierry Reding
2021-11-30  1:41   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 12/16] dt-bindings: firmware: tegra: " Thierry Reding
2021-11-30  1:43   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 13/16] dt-bindings: i2c: tegra-bpmp: " Thierry Reding
2021-11-23 16:34   ` Rob Herring
2021-11-30  1:44   ` Rob Herring
2021-12-01 17:42     ` Thierry Reding
2021-12-01 18:42       ` Rob Herring
2021-12-02 17:55         ` Thierry Reding [this message]
2021-12-02 21:08           ` Rob Herring
2021-12-02 22:38             ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 14/16] dt-bindings: thermal: tegra186-bpmp: " Thierry Reding
2021-11-30  1:44   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 15/16] dt-bindings: serial: tegra-tcu: " Thierry Reding
2021-11-23 16:34   ` Rob Herring
2021-11-30  1:45   ` Rob Herring
2021-11-19 14:38 ` [PATCH v2 16/16] dt-bindings: serial: Document Tegra234 TCU Thierry Reding
2021-11-23 16:34   ` Rob Herring
2021-11-30  1:45   ` Rob Herring
2021-12-09 17:05 ` [PATCH v2 00/16] dt-bindings: Convert Tegra DT bindings to json-schema Thierry Reding

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=YakIePafm3t6rJLE@orome.fritz.box \
    --to=thierry.reding@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-tegra@vger.kernel.org \
    --cc=robh@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).