linux-kernel - Re: [PATCH 1/2] dt-bindings: display/panel: Add Innolux EJ030NA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Jul 2021 14:30:13 -0600
From:   Rob Herring <robh@...nel.org>
To:     Paul Cercueil <paul@...pouillou.net>
Cc:     Sam Ravnborg <sam@...nborg.org>,
        Thierry Reding <thierry.reding@...il.com>,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, list@...ndingux.net,
        Christophe Branchereau <cbranchereau@...il.com>
Subject: Re: [PATCH 1/2] dt-bindings: display/panel: Add Innolux EJ030NA

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.

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