Re: [PATCH] arm64: dts: Reformat PCI ranges/dma-ranges entries

From: Rob Herring <robh@kernel.org>
To: Olof Johansson <olof@lixom.net>
Cc: Nishanth Menon <nm@ti.com>, Andrew Lunn <andrew@lunn.ch>,
	Heiko Stuebner <heiko@sntech.de>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Fabio Estevam <festevam@gmail.com>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Khuong Dinh <khuong@os.amperecomputing.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Gregory Clement <gregory.clement@bootlin.com>,
	Michal Simek <michal.simek@xilinx.com>,
	Wei Xu <xuwei5@hisilicon.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Andy Gross <agross@kernel.org>,
	NXP Linux Team <linux-imx@nxp.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	devicetree@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>, SoC Team <soc@kernel.org>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	Li Yang <leoyang.li@nxp.com>, Tero Kristo <t-kristo@ti.com>,
	Robert Richter <rrichter@marvell.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>
Subject: Re: [PATCH] arm64: dts: Reformat PCI ranges/dma-ranges entries
Date: Fri, 21 Aug 2020 10:14:03 -0600	[thread overview]
Message-ID: <CAL_JsqLfzDMJXDdqtVBYWrvuB8kBDHECWmNkS5EJStiwSFtp-g@mail.gmail.com> (raw)
In-Reply-To: <20200821011237.GA4527@lx2k>

On Thu, Aug 20, 2020 at 8:53 PM Olof Johansson <olof@lixom.net> wrote:
>
> On Wed, Aug 19, 2020 at 04:17:50PM -0600, Rob Herring wrote:
> > While bracketing doesn't matter for a DTB, the DT schema checks rely on
> > bracketing around each distinct entry. Reformat ranges and dma-ranges
> > entries to fix warnings such as:
> >
> > arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dt.yaml: pcie@f8000000: ranges: [[2197815296, 0, 4194304000, 0, 4194304000, 0, 31457280, 2164260864, 0, 4225761280, 0, 4225761280, 0, 1048576]] is not valid under any of the given schemas (Possible causes of the failure):
> >         arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dt.yaml: pcie@f8000000: ranges: True was expected
> >         arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dt.yaml: pcie@f8000000: ranges:0: [2197815296, 0, 4194304000, 0, 4194304000, 0, 31457280, 2164260864, 0, 4225761280, 0, 4225761280, 0, 1048576] is too long
> >         arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dt.yaml: pcie@f8000000: ranges:0:0: 2197815296 is not one of [16777216, 33554432, 50331648, 1107296256, 1124073472]
>
> Seems like a bug in your tool? Why would we bother with this churn?

It's a feature. :)

In this case, with the entries bracketed, we can check the PCI top
address cell contents in the common PCI schema and check how many
ranges entries in the specific bridge schemas if they have some
constraints. The use of bracketing is useful to defining the number of
entries not just for ranges, but everywhere. A device binding defines
how many register regions or interrupts for example. It makes sense to
delineate entries in some way. While yes, we have #.*-cells, there's
not really any way to handle that in json-schema. And let's face it,
#.*-cells is an odd construct.

Currently, the dtc dts->yaml output maintains all this formatting. I
suppose we could change that such that we parse #.*-cells and define
the boundaries based on them. But then dtc has to know about every
case of #.*-cells. That's not impossible to do, but doesn't keep the
tool and binding data separate.

Looking at it another way, do we really want to just allow anything? A
device with 3 interrupts could be written as:

interrupts = <1>, <2>, <3>;
interrupts = <1 2 3>;
interrupts = <1>, <2 3>;
interrupts = [ 00 00 00 01 00 00 00 02 00 00 00 03 ];

Or can we have some coding standards that are no more onerous or
pedantic than what we have everywhere else?

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel