From: Marc Zyngier <maz@kernel.org>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
Rob Herring <robh+dt@kernel.org>, Shawn Guo <shawnguo@kernel.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Leo Li <leoyang.li@nxp.com>,
Biwen Li <biwen.li@nxp.com>, "Z.Q. Hou" <zhiqiang.hou@nxp.com>,
Kurt Kanzenbach <kurt@linutronix.de>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [PATCH v2 devicetree] Revert "arm64: dts: freescale: Fix 'interrupt-map' parent address cells"
Date: Sun, 02 Jan 2022 13:08:28 +0000 [thread overview]
Message-ID: <c5b9cec617100b891b7fceaee8655ba8@kernel.org> (raw)
In-Reply-To: <20211231181350.qwfnrwvdfnfssdjt@skbuf>
On 2021-12-31 18:13, Vladimir Oltean wrote:
> Hello,
>
> On Tue, Dec 14, 2021 at 03:58:52PM +0200, Vladimir Oltean wrote:
>> This reverts commit 869f0ec048dc8fd88c0b2003373bd985795179fb. That
>> updated the expected device tree binding format for the ls-extirq
>> driver, without also updating the parsing code (ls_extirq_parse_map)
>> to the new format.
>>
>> The context is that the ls-extirq driver uses the standard
>> "interrupt-map" OF property in a non-standard way, as suggested by
>> Rob Herring during review:
>> https://lore.kernel.org/lkml/20190927161118.GA19333@bogus/
>>
>> This has turned out to be problematic, as Marc Zyngier discovered
>> through commit 041284181226 ("of/irq: Allow matching of an
>> interrupt-map
>> local to an interrupt controller"), later fixed through commit
>> de4adddcbcc2 ("of/irq: Add a quirk for controllers with their own
>> definition of interrupt-map"). Marc's position, expressed on multiple
>> opportunities, is that:
>>
>> (a) [ making private use of the reserved "interrupt-map" name in a
>> driver ] "is wrong, by the very letter of what an interrupt-map
>> means. If the interrupt map points to an interrupt controller,
>> that's the target for the interrupt."
>> https://lore.kernel.org/lkml/87k0g8jlmg.wl-maz@kernel.org/
>>
>> (b) [ updating the driver's bindings to accept a non-reserved name for
>> this property, as an alternative, is ] "is totally pointless.
>> These
>> machines have been in the wild for years, and existing DTs will be
>> there *forever*."
>> https://lore.kernel.org/lkml/87ilvrk1r0.wl-maz@kernel.org/
>>
>> Considering the above, the Linux kernel has quirks in place to deal
>> with
>> the ls-extirq's non-standard use of the "interrupt-map". These quirks
>> may be needed in other operating systems that consume this device
>> tree,
>> yet this is seen as the only viable solution.
>>
>> 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.
>>
>> This change restores LS1088A, LS2088A/LS2085A and LX2160A to their
>> previous bindings, which allows these systems to continue to use
>> external interrupt lines with the correct polarity.
>>
>> Fixes: 869f0ec048dc ("arm64: dts: freescale: Fix 'interrupt-map'
>> parent address cells")
>> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>> ---
>> v1->v2: remove the other 9 patches that rename "interrupt-map" to
>> "fsl,extirq-map", at Marc's suggestion.
>
> Could this patch be considered for merging in v5.16? The problem is
> going to be quite a bit more severe and tricky to fix otherwise.
> Thanks.
FWIW:
Acked-by: Marc Zyngier <maz@kernel.org>
Rob, Shawn, can you please queue this as an urgent fix for 5.16?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2022-01-02 13:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-14 13:58 [PATCH v2 devicetree] Revert "arm64: dts: freescale: Fix 'interrupt-map' parent address cells" Vladimir Oltean
2021-12-31 18:13 ` Vladimir Oltean
2022-01-02 13:08 ` Marc Zyngier [this message]
2022-01-03 11:30 ` Shawn Guo
2022-02-09 11:54 ` Ioana Ciornei
2022-03-10 20:09 ` Vladimir Oltean
2022-03-14 15:15 ` Rob Herring
2022-03-14 15:34 ` Marc Zyngier
2022-03-14 16:08 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c5b9cec617100b891b7fceaee8655ba8@kernel.org \
--to=maz@kernel.org \
--cc=biwen.li@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=kurt@linutronix.de \
--cc=leoyang.li@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=robh+dt@kernel.org \
--cc=shawnguo@kernel.org \
--cc=vladimir.oltean@nxp.com \
--cc=zhiqiang.hou@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).