| 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
| ||
|
Message-ID: <CAL_JsqKeTmew8ZaNsXqVsXCrkW9zb1V2JcANRVPXyEHqZnVWzA@mail.gmail.com>
Date: Wed, 19 Jan 2022 09:28:59 -0600
From: Rob Herring <robh@...nel.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: devicetree@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
Chun-Kuang Hu <chunkuang.hu@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
Vinod Koul <vkoul@...nel.org>,
Georgi Djakov <djakov@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Marc Zyngier <maz@...nel.org>, Joerg Roedel <joro@...tes.org>,
Lee Jones <lee.jones@...aro.org>,
Daniel Thompson <daniel.thompson@...aro.org>,
Jingoo Han <jingoohan1@...il.com>, Pavel Machek <pavel@....cz>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
Jakub Kicinski <kuba@...nel.org>,
Wolfgang Grandegger <wg@...ndegger.com>,
Marc Kleine-Budde <mkl@...gutronix.de>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Kalle Valo <kvalo@...nel.org>,
Viresh Kumar <vireshk@...nel.org>,
Stephen Boyd <sboyd@...nel.org>,
Kishon Vijay Abraham I <kishon@...com>,
Linus Walleij <linus.walleij@...aro.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Kevin Hilman <khilman@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Sebastian Reichel <sre@...nel.org>,
Mark Brown <broonie@...nel.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Zhang Rui <rui.zhang@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Sudeep Holla <sudeep.holla@....com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
"open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)"
<linux-ide@...r.kernel.org>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
"open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM"
<dmaengine@...r.kernel.org>,
"open list:THERMAL" <linux-pm@...r.kernel.org>,
Linux IOMMU <iommu@...ts.linux-foundation.org>,
Linux LED Subsystem <linux-leds@...r.kernel.org>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
netdev <netdev@...r.kernel.org>, linux-can@...r.kernel.org,
linux-wireless <linux-wireless@...r.kernel.org>,
"open list:GENERIC PHY FRAMEWORK" <linux-phy@...ts.infradead.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
linux-riscv@...ts.infradead.org, linux-remoteproc@...r.kernel.org,
alsa-devel@...a-project.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: Improve phandle-array schemas
On Wed, Jan 19, 2022 at 4:35 AM Vladimir Oltean <olteanv@...il.com> wrote:
>
> On Tue, Jan 18, 2022 at 07:50:38PM -0600, Rob Herring wrote:
> > The 'phandle-array' type is a bit ambiguous. It can be either just an
> > array of phandles or an array of phandles plus args. Many schemas for
> > phandle-array properties aren't clear in the schema which case applies
> > though the description usually describes it.
> >
> > The array of phandles case boils down to needing:
> >
> > items:
> > maxItems: 1
> >
> > The phandle plus args cases should typically take this form:
> >
> > items:
> > - items:
> > - description: A phandle
> > - description: 1st arg cell
> > - description: 2nd arg cell
> >
> > With this change, some examples need updating so that the bracketing of
> > property values matches the schema.
> > ---
> (...)
> > diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
> > index 702df848a71d..c504feeec6db 100644
> > --- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
> > +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
> > @@ -34,6 +34,8 @@ properties:
> > full routing information must be given, not just the one hop
> > routes to neighbouring switches
> > $ref: /schemas/types.yaml#/definitions/phandle-array
> > + items:
> > + maxItems: 1
> >
> > ethernet:
> > description:
>
> For better or worse, the mainline cases of this property all take the
> form of:
>
> arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
> link = <&switch1port9 &switch2port9>;
> link = <&switch1port10 &switch0port10>;
> arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> link = <&switch1port6
> &switch2port9>;
> link = <&switch1port5
> &switch0port5>;
> arch/arm/boot/dts/vf610-zii-scu4-aib.dts
> link = <&switch1port10
> &switch3port10
> &switch2port10>;
> link = <&switch3port10
> &switch2port10>;
> link = <&switch1port9
> &switch0port10>;
>
> So not really an array of phandles.
Either form is an array. The DT yaml encoding maintains the
bracketing, so how the schema is defined matters. To some extent the
tools will process the schema to support both forms of bracketing, but
this has turned out to be fragile and just doesn't work for phandle
arrays. I'm working on further changes that will get rid of the yaml
encoded DT format and validate DTB files directly. These obviously
have no bracketing and needing the DTS source files to change goes
away. However, to be able to construct the internal format for
validation, I do need the schemas to have more information on what
exactly the phandle-array contains.
Rob
Powered by blists - more mailing lists