linux-kernel - Re: [PATCH 00/18] dt-bindings: irqchip: include generic schema

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]

Date:   Tue, 22 Mar 2022 19:36:21 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Rob Herring <robh@...nel.org>
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 21/03/2022 19:53, Rob Herring wrote:
> 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.

Indeed there were cases of MSI and interrupt controller.

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

Yes, that's a side effect. Maybe my series should be abandoned.

Best regards,
Krzysztof