All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <mripard@kernel.org>
To: Torsten Duwe <duwe@lst.de>
Cc: Chen-Yu Tsai <wens@csie.org>, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Icenowy Zheng <icenowy@aosc.io>,
	Sean Paul <seanpaul@chromium.org>,
	Vasily Khoruzhick <anarsoul@gmail.com>,
	Harald Geyer <harald@ccbib.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
Date: Sun, 3 Nov 2019 17:01:14 +0100	[thread overview]
Message-ID: <20191103160114.GD7001@gilmour> (raw)
In-Reply-To: <20191031145224.GA5973@lst.de>

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

On Thu, Oct 31, 2019 at 03:52:24PM +0100, Torsten Duwe wrote:
> On Thu, Oct 31, 2019 at 01:51:00PM +0100, Maxime Ripard wrote:
> > On Tue, Oct 29, 2019 at 01:16:57PM +0100, Torsten Duwe wrote:
> > > +
> > > +  ports:
> > > +    anyOf:
> > > +      - port@0:
> > > +        description: Video port for LVTTL input
> > > +      - port@1:
> > > +        description: Video port for eDP output (panel or connector).
> > > +                     May be omitted if EDID works reliably.
> > > +    required:
> > > +      - port@0
> >
> > Have you tried to validate those two ports in a DT?
>
> Yes, it validates as expected, like I wrote. Various sources told me that
> json-schema is not always straightforward so I assumed anyOf was OK.
>
> > I'm not quite sure what you wanted to express with that anyOf, but if
> > it was something like port@0 is mandatory, and port@1 is optional, it
> > should be something like this:
> >
> > properties:
> >
> >   ...
> >
> >   ports:
> >     type: object
> >
> >     properties:
> >       port@0:
> >         type: object
> >         description: |
> > 	  Video port for LVTTL input
> >
> >       port@1:
> >         type: object
> >         description: |
> > 	  Video port for eDP output (..)
> >
> >     required:
> >       - port@0
> >
> > This way, you express that both port@0 and port@1 must by nodes, under
> > a node called ports, and port@0 is mandatory.
>
> That validates, too. Looks better, admittedly. I don't have a strong
> opinion here. It's just that Rob wrote in
> <CAL_JsqKAU3WG3L=KP8A8u4vW=q_BQWPN-m_c+ADOwTioJ2-cmg@mail.gmail.com>:
>
> | For this case specifically, we do need to define a common graph
> | schema, but haven't yet. You can assume we do and only really need to
> | capture what Maxime said above.
> (your points back then were port@N descriptions and neccessity for port@0)
>
> Are you sure that "object" is specific enough?

Possibly not, but at least it checks that there's indeed something
called port@0 (and port@1), and that they are both nodes (and not
properties).

We can probably refine this further, but this is good enough at the
moment.

> > You should even push this a bit further by adding
> > additionalProperties: false to prevent a DT from having undocumented
> > properties and children for the main node and ports node.
>
> You mean like
>
> | jsonschema.exceptions.SchemaError: Additional properties are not allowed ('unevaluatedProperties' was unexpected)
> [...]
> | On schema:
> |    {'$id': 'http://devicetree.org/schemas/watchdog/allwinner,sun4i-a10-wdt.yaml#',
> [...]
> |      'unevaluatedProperties': False}
>
> ? ;-)

That would be on the meta-schema, but yes, we want to trigger warnings
on something that isn't described.

>
> But yes, this patch series passes even with additionalProperties: false.
>
> In which form would you like to receive the update?

Please send a new version.

Thanks!
Maxime

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

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <mripard@kernel.org>
To: Torsten Duwe <duwe@lst.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, David Airlie <airlied@linux.ie>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Andrzej Hajda <a.hajda@samsung.com>, Chen-Yu Tsai <wens@csie.org>,
	Rob Herring <robh+dt@kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel@ffwll.ch>, Harald Geyer <harald@ccbib.org>,
	Sean Paul <seanpaul@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Icenowy Zheng <icenowy@aosc.io>
Subject: Re: [PATCH v4 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
Date: Sun, 3 Nov 2019 17:01:14 +0100	[thread overview]
Message-ID: <20191103160114.GD7001@gilmour> (raw)
In-Reply-To: <20191031145224.GA5973@lst.de>


[-- Attachment #1.1: Type: text/plain, Size: 2901 bytes --]

On Thu, Oct 31, 2019 at 03:52:24PM +0100, Torsten Duwe wrote:
> On Thu, Oct 31, 2019 at 01:51:00PM +0100, Maxime Ripard wrote:
> > On Tue, Oct 29, 2019 at 01:16:57PM +0100, Torsten Duwe wrote:
> > > +
> > > +  ports:
> > > +    anyOf:
> > > +      - port@0:
> > > +        description: Video port for LVTTL input
> > > +      - port@1:
> > > +        description: Video port for eDP output (panel or connector).
> > > +                     May be omitted if EDID works reliably.
> > > +    required:
> > > +      - port@0
> >
> > Have you tried to validate those two ports in a DT?
>
> Yes, it validates as expected, like I wrote. Various sources told me that
> json-schema is not always straightforward so I assumed anyOf was OK.
>
> > I'm not quite sure what you wanted to express with that anyOf, but if
> > it was something like port@0 is mandatory, and port@1 is optional, it
> > should be something like this:
> >
> > properties:
> >
> >   ...
> >
> >   ports:
> >     type: object
> >
> >     properties:
> >       port@0:
> >         type: object
> >         description: |
> > 	  Video port for LVTTL input
> >
> >       port@1:
> >         type: object
> >         description: |
> > 	  Video port for eDP output (..)
> >
> >     required:
> >       - port@0
> >
> > This way, you express that both port@0 and port@1 must by nodes, under
> > a node called ports, and port@0 is mandatory.
>
> That validates, too. Looks better, admittedly. I don't have a strong
> opinion here. It's just that Rob wrote in
> <CAL_JsqKAU3WG3L=KP8A8u4vW=q_BQWPN-m_c+ADOwTioJ2-cmg@mail.gmail.com>:
>
> | For this case specifically, we do need to define a common graph
> | schema, but haven't yet. You can assume we do and only really need to
> | capture what Maxime said above.
> (your points back then were port@N descriptions and neccessity for port@0)
>
> Are you sure that "object" is specific enough?

Possibly not, but at least it checks that there's indeed something
called port@0 (and port@1), and that they are both nodes (and not
properties).

We can probably refine this further, but this is good enough at the
moment.

> > You should even push this a bit further by adding
> > additionalProperties: false to prevent a DT from having undocumented
> > properties and children for the main node and ports node.
>
> You mean like
>
> | jsonschema.exceptions.SchemaError: Additional properties are not allowed ('unevaluatedProperties' was unexpected)
> [...]
> | On schema:
> |    {'$id': 'http://devicetree.org/schemas/watchdog/allwinner,sun4i-a10-wdt.yaml#',
> [...]
> |      'unevaluatedProperties': False}
>
> ? ;-)

That would be on the meta-schema, but yes, we want to trigger warnings
on something that isn't described.

>
> But yes, this patch series passes even with additionalProperties: false.
>
> In which form would you like to receive the update?

Please send a new version.

Thanks!
Maxime

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

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-11-03 16:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29 15:38 [PATCH v4 0/7] Add anx6345 DP/eDP bridge for Olimex Teres-I Torsten Duwe
2019-10-29 15:38 ` Torsten Duwe
2019-10-29 15:38 ` Torsten Duwe
2019-10-29 12:16 ` [PATCH v4 1/7] drm/bridge: move ANA78xx driver to analogix subdirectory Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16 ` [PATCH v4 4/7] drm/bridge: Prepare Analogix anx6345 support Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16 ` [PATCH v4 5/7] drm/bridge: Add " Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16 ` [PATCH v4 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16 ` [PATCH v4 3/7] drm/bridge: extract some Analogix I2C DP common code Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16 ` [PATCH v4 2/7] drm/bridge: split some definitions of ANX78xx to dedicated headers Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16 ` [PATCH v4 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-29 12:16   ` Torsten Duwe
2019-10-31 12:51   ` Maxime Ripard
2019-10-31 12:51     ` Maxime Ripard
2019-10-31 12:51     ` Maxime Ripard
2019-10-31 14:52     ` Torsten Duwe
2019-10-31 14:52       ` Torsten Duwe
2019-10-31 14:52       ` Torsten Duwe
2019-11-03 16:01       ` Maxime Ripard [this message]
2019-11-03 16:01         ` Maxime Ripard

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=20191103160114.GD7001@gilmour \
    --to=mripard@kernel.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=anarsoul@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=duwe@lst.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=harald@ccbib.org \
    --cc=icenowy@aosc.io \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=seanpaul@chromium.org \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.com \
    --cc=wens@csie.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.