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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YjjJpxLWJ/YOe0OX@robh.at.kernel.org>
Date:   Mon, 21 Mar 2022 13:53:27 -0500
From:   Rob Herring <robh@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Andreas Färber <afaerber@...e.de>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Linus Walleij <linusw@...nel.org>,
        Imre Kaloz <kaloz@...nwrt.org>,
        Krzysztof Halasa <khalasa@...p.pl>,
        Michael Walle <michael@...le.cc>,
        Mark-PK Tsai <mark-pk.tsai@...iatek.com>,
        Daniel Palmer <daniel@...ngy.jp>,
        Jonathan Neuschäfer <j.neuschaefer@....net>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Nishanth Menon <nm@...com>, Tero Kristo <kristo@...nel.org>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Cristian Ciocaltea <cristian.ciocaltea@...il.com>,
        Joakim Zhang <qiangqing.zhang@....com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Paul Cercueil <paul@...pouillou.net>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        Jason Cooper <jason@...edaemon.net>,
        Paul Burton <paulburton@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Birger Koblitz <mail@...ger-koblitz.de>,
        Bert Vermeulen <bert@...t.com>,
        John Crispin <john@...ozen.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Sagar Kadam <sagar.kadam@...ive.com>,
        Suman Anna <s-anna@...com>, Lokesh Vutla <lokeshvutla@...com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-actions@...ts.infradead.org, openbmc@...ts.ozlabs.org,
        linux-riscv@...ts.infradead.org, linux-oxnas@...ups.io
Subject: Re: [PATCH 00/18] dt-bindings: irqchip: include generic schema

On Thu, Mar 17, 2022 at 12:55:24PM +0100, Krzysztof Kozlowski wrote:
> Hi,
> 
> The DTS patches can be picked up independently.
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (18):
>   ARM: dts: nspire: use lower case hex addresses in node unit addresses
>   ARM: dts: ox820: align interrupt controller node name with dtschema
>   ARM: dts: socfpga: align interrupt controller node name with dtschema
>   dt-bindings: irqchip: actions,owl-sirq: include generic schema
>   dt-bindings: irqchip: fsl: include generic schema
>   dt-bindings: irqchip: ingenic: include generic schema
>   dt-bindings: irqchip: intel,ixp4xx: include generic schema
>   dt-bindings: irqchip: kontron,sl28cpld: include generic schema
>   dt-bindings: irqchip: loongson: include generic schema
>   dt-bindings: irqchip: microchip,eic: include generic schema
>   dt-bindings: irqchip: mrvl,intc: include generic schema
>   dt-bindings: irqchip: mstar,mst-intc: include generic schema
>   dt-bindings: irqchip: mti,gic: include generic schema
>   dt-bindings: irqchip: nuvoton,wpcm450-aic: include generic schema
>   dt-bindings: irqchip: realtek,rtl-intc: include generic schema
>   dt-bindings: irqchip: renesas: include generic schema
>   dt-bindings: irqchip: sifive: include generic schema
>   dt-bindings: irqchip: ti: include generic schema

I'm somewhat on the fence about these. Originally only devices with a 
bus or child nodes included a common schema. For 'simple' providers 
with mainly a '#<provider>-cells' property, we had to set the 
constraints on the number of cells anyways, so referencing another 
schema doesn't save anything. It is nice to declare the 'class' of the 
device though.

It makes the schema be applied twice (if the node name matches). That's 
not all bad because it finds cases of wrong node name. However, 
sometimes we have devices which are multiple providers and can't set the 
node name. So those can't reference interrupt-controller.yaml.

It also means that 'interrupt-map' for example is now valid. That could 
be fixed by splitting 'interrupt-map' related properties to its own 
schema. 

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ