Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Mon, 21 Mar 2022 13:53:27 -0500
From:   Rob Herring <robh@kernel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Marc Zyngier <maz@kernel.org>,
        Krzysztof Kozlowski <krzk+dt@kernel.org>,
        =?UTF-8?Q?Andreas_F=C3=A4rber?= <afaerber@suse.de>,
        Manivannan Sadhasivam <mani@kernel.org>,
        Linus Walleij <linusw@kernel.org>,
        Imre Kaloz <kaloz@openwrt.org>,
        Krzysztof Halasa <khalasa@piap.pl>,
        Michael Walle <michael@walle.cc>,
        Mark-PK Tsai <mark-pk.tsai@mediatek.com>,
        Daniel Palmer <daniel@thingy.jp>,
        =?UTF-8?Q?Jonathan_Neusch=C3=A4fer?= <j.neuschaefer@gmx.net>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Nishanth Menon <nm@ti.com>, Tero Kristo <kristo@kernel.org>,
        Santosh Shilimkar <ssantosh@kernel.org>,
        Neil Armstrong <narmstrong@baylibre.com>,
        Dinh Nguyen <dinguyen@kernel.org>,
        Cristian Ciocaltea <cristian.ciocaltea@gmail.com>,
        Joakim Zhang <qiangqing.zhang@nxp.com>,
        Lucas Stach <l.stach@pengutronix.de>,
        Paul Cercueil <paul@crapouillou.net>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>,
        Claudiu Beznea <claudiu.beznea@microchip.com>,
        Jason Cooper <jason@lakedaemon.net>,
        Paul Burton <paulburton@kernel.org>,
        Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        Birger Koblitz <mail@birger-koblitz.de>,
        Bert Vermeulen <bert@biot.com>,
        John Crispin <john@phrozen.org>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        Sagar Kadam <sagar.kadam@sifive.com>,
        Suman Anna <s-anna@ti.com>, Lokesh Vutla <lokeshvutla@ti.com>,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-actions@lists.infradead.org, openbmc@lists.ozlabs.org,
        linux-riscv@lists.infradead.org, linux-oxnas@groups.io
Subject: Re: [PATCH 00/18] dt-bindings: irqchip: include generic schema
Message-ID: <YjjJpxLWJ/YOe0OX@robh.at.kernel.org>
References: <20220317115542.450032-1-krzysztof.kozlowski@canonical.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220317115542.450032-1-krzysztof.kozlowski@canonical.com>
Precedence: bulk

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