From: Paul Cercueil <paul@crapouillou.net>
To: Rob Herring <robh@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>,
Thierry Reding <thierry.reding@gmail.com>,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, list@opendingux.net,
Christophe Branchereau <cbranchereau@gmail.com>
Subject: Re: [PATCH 1/2] dt-bindings: display/panel: Add Innolux EJ030NA
Date: Wed, 14 Jul 2021 21:40:46 +0100 [thread overview]
Message-ID: <YF59WQ.VTZ17PPSJ9I02@crapouillou.net> (raw)
In-Reply-To: <20210714203013.GA3287208@robh.at.kernel.org>
Hi Rob,
Le mer., juil. 14 2021 at 14:30:13 -0600, Rob Herring <robh@kernel.org>
a écrit :
> On Sat, Jul 10, 2021 at 11:21:56AM +0100, Paul Cercueil wrote:
>>
>> [...]
>>
>> > > I am not sure; the doc states that this (additionalProperties:
>> > > false) "can't
>> > > be used in case where another schema is referenced", which is
>> the
>> > > case here,
>> > > as we include "panel-common.yaml".
>> >
>> > This DT schema already list all relevant properties like:
>> >
>> > backlight: true
>> >
>> > So "additionalProperties: false" tells that no other properties
>> are
>> > allowed other than the listed properties.
>> >
>> > To my best understanding unevaluatedProperties: false is less
>> strict and
>> > should be used if one does not list all possilbe properties.
>
> Right. There's some value of listing which common properties you are
> using as well.
>
>> > This could be the case for a panel haging below a SPI controller
>> as in
>> > this case. So in other words giving this some extra thought I
>> think
>> > unevaluatedProperties: false is OK here.
>>
>> A panel below a SPI controller would have all its SPI-specific
>> properties
>> covered by spi-controller.yaml, I believe? So maybe
>> "additionalProperties:
>> false" would work?
>
> No. Because spi-controller.yaml is evaluated on the SPI host node and
> this one is evaluated on the SPI slave. There's some work to address
> this, but it means every SPI slave will have to reference a SPI device
> schema. The bigger issue here is SPI controller specific device
> properties. So for this case, we'll have to use unevaluatedProperties.
Thank you for the clarification.
Cheers,
-Paul
>>
>> In any case, if I use "additionalProperties: false", "make
>> dt_binding_check"
>> complains that my example's "spi-max-frequency" property is not
>> covered. So
>> maybe you are right.
>>
>> > So my r-b is ok if you keep it as it.
>> >
>> > PS. Where do you guys hang out with the downfall of freenode -
>> somewhere
>> > on oftc?
>>
>> We moved to #opendingux on Libera.
>>
>> Cheers,
>> -Paul
>>
>>
>>
WARNING: multiple messages have this Message-ID (diff)
From: Paul Cercueil <paul@crapouillou.net>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org,
Christophe Branchereau <cbranchereau@gmail.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Thierry Reding <thierry.reding@gmail.com>,
list@opendingux.net, Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH 1/2] dt-bindings: display/panel: Add Innolux EJ030NA
Date: Wed, 14 Jul 2021 21:40:46 +0100 [thread overview]
Message-ID: <YF59WQ.VTZ17PPSJ9I02@crapouillou.net> (raw)
In-Reply-To: <20210714203013.GA3287208@robh.at.kernel.org>
Hi Rob,
Le mer., juil. 14 2021 at 14:30:13 -0600, Rob Herring <robh@kernel.org>
a écrit :
> On Sat, Jul 10, 2021 at 11:21:56AM +0100, Paul Cercueil wrote:
>>
>> [...]
>>
>> > > I am not sure; the doc states that this (additionalProperties:
>> > > false) "can't
>> > > be used in case where another schema is referenced", which is
>> the
>> > > case here,
>> > > as we include "panel-common.yaml".
>> >
>> > This DT schema already list all relevant properties like:
>> >
>> > backlight: true
>> >
>> > So "additionalProperties: false" tells that no other properties
>> are
>> > allowed other than the listed properties.
>> >
>> > To my best understanding unevaluatedProperties: false is less
>> strict and
>> > should be used if one does not list all possilbe properties.
>
> Right. There's some value of listing which common properties you are
> using as well.
>
>> > This could be the case for a panel haging below a SPI controller
>> as in
>> > this case. So in other words giving this some extra thought I
>> think
>> > unevaluatedProperties: false is OK here.
>>
>> A panel below a SPI controller would have all its SPI-specific
>> properties
>> covered by spi-controller.yaml, I believe? So maybe
>> "additionalProperties:
>> false" would work?
>
> No. Because spi-controller.yaml is evaluated on the SPI host node and
> this one is evaluated on the SPI slave. There's some work to address
> this, but it means every SPI slave will have to reference a SPI device
> schema. The bigger issue here is SPI controller specific device
> properties. So for this case, we'll have to use unevaluatedProperties.
Thank you for the clarification.
Cheers,
-Paul
>>
>> In any case, if I use "additionalProperties: false", "make
>> dt_binding_check"
>> complains that my example's "spi-max-frequency" property is not
>> covered. So
>> maybe you are right.
>>
>> > So my r-b is ok if you keep it as it.
>> >
>> > PS. Where do you guys hang out with the downfall of freenode -
>> somewhere
>> > on oftc?
>>
>> We moved to #opendingux on Libera.
>>
>> Cheers,
>> -Paul
>>
>>
>>
next prev parent reply other threads:[~2021-07-14 20:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-25 12:10 [PATCH 1/2] dt-bindings: display/panel: Add Innolux EJ030NA Paul Cercueil
2021-06-25 12:10 ` Paul Cercueil
2021-06-25 12:10 ` [PATCH 2/2] drm/panel: Add Innolux EJ030NA 3.0" 320x480 panel Paul Cercueil
2021-06-25 12:10 ` Paul Cercueil
2021-07-10 6:18 ` Sam Ravnborg
2021-07-14 20:51 ` Paul Cercueil
2021-07-14 20:51 ` Paul Cercueil
2021-07-10 6:14 ` [PATCH 1/2] dt-bindings: display/panel: Add Innolux EJ030NA Sam Ravnborg
2021-07-10 9:42 ` Paul Cercueil
2021-07-10 9:42 ` Paul Cercueil
2021-07-10 9:59 ` Sam Ravnborg
2021-07-10 10:21 ` Paul Cercueil
2021-07-10 10:21 ` Paul Cercueil
2021-07-14 20:30 ` Rob Herring
2021-07-14 20:30 ` Rob Herring
2021-07-14 20:40 ` Paul Cercueil [this message]
2021-07-14 20:40 ` Paul Cercueil
2021-07-14 20:30 ` Rob Herring
2021-07-14 20:30 ` Rob Herring
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=YF59WQ.VTZ17PPSJ9I02@crapouillou.net \
--to=paul@crapouillou.net \
--cc=cbranchereau@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=list@opendingux.net \
--cc=robh@kernel.org \
--cc=sam@ravnborg.org \
--cc=thierry.reding@gmail.com \
/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.