[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k0cwzgy0.wl-maz@kernel.org>
Date: Mon, 14 Mar 2022 15:34:15 +0000
From: Marc Zyngier <maz@...nel.org>
To: Rob Herring <robh+dt@...nel.org>
Cc: Vladimir Oltean <vladimir.oltean@....com>,
devicetree@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Shawn Guo <shawnguo@...nel.org>, Li Yang <leoyang.li@....com>,
Biwen Li <biwen.li@....com>,
Zhiqiang Hou <Zhiqiang.Hou@....com>,
Kurt Kanzenbach <kurt@...utronix.de>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v2 devicetree] Revert "arm64: dts: freescale: Fix 'interrupt-map' parent address cells"
On Mon, 14 Mar 2022 15:15:15 +0000,
Rob Herring <robh+dt@...nel.org> wrote:
>
> On Tue, Dec 14, 2021 at 6:59 AM Vladimir Oltean <vladimir.oltean@....com> wrote:
> > Therefore, the premise of the patch being reverted here is invalid.
> > It doesn't matter whether the driver, in its non-standard use of the
> > property, complies to the standard format or not, since this property
> > isn't expected to be used for interrupt translation by the core.
>
> I disagree. The non-standard part is that 'interrupt-map' translation
> is not transparent. 'interrupt-map' that can't be parsed in the
> standard way is just wrong, and I imagine was never the intention
> here. We simply cannot have platforms defining their own format for
> standard properties.
That ship sailed a long while ago. We have a list of offenders, and we
can make sure we don't get additional ones.
> Reverting this will cause dtc warnings now (IIRC) and just kicks the
> can down the road. Reverting is fine for now (I gave Arnd the okay on
> IRC), but I think the parsing will need to be updated to honor
> #address-cells and detect an old DT (probably by looking at the total
> size of 'interrupt-map') and mark that change for stable. That would
> only leave a new dt with an old kernel without stable updates broken.
> Seems unlikely a device is getting firmware updates, but not OS
> updates.
Being able to rollback firmware and OS independently is important. The
tooling can be taught about the broken instances, which should be
enough. Adding to the parsing only makes things harder to maintain,
for no real gain.
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists