[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqL6HV-C6+9Pna_8GVT5V+uEzcYcPDaS1m6AK8LhsWnFaw@mail.gmail.com>
Date: Tue, 7 Dec 2021 14:08:27 -0600
From: Rob Herring <robh+dt@...nel.org>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: devicetree@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
"maintainer:BROADCOM IPROC ARM ARCHITECTURE"
<bcm-kernel-feedback-list@...adcom.com>,
"open list:PCI SUBSYSTEM" <linux-pci@...r.kernel.org>,
"moderated list:BROADCOM IPROC ARM ARCHITECTURE"
<linux-arm-kernel@...ts.infradead.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/5] ARM: dts: Cygnus: Fixed iProc PCIe controller properties
On Tue, Dec 7, 2021 at 11:44 AM Florian Fainelli <f.fainelli@...il.com> wrote:
>
> On 12/7/21 5:49 AM, Rob Herring wrote:
> > On Mon, Dec 6, 2021 at 12:52 PM Florian Fainelli <f.fainelli@...il.com> wrote:
> >>
> >> Rename the msi controller unit name to 'msi' to avoid collisions
> >> with the 'msi-controller' boolean property and add the missing
> >> 'interrupt-controller' property which is necessary. We also need to
> >> re-arrange the 'ranges' property to show the two cells as being separate
> >> instead of combined since the DT checker is not able to differentiate
> >> otherwise.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
> >> ---
> >> arch/arm/boot/dts/bcm-cygnus.dtsi | 14 ++++++++------
> >> 1 file changed, 8 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> >> index 8ecb7861ce10..ea19d1b56400 100644
> >> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> >> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> >> @@ -263,6 +263,7 @@ pcie0: pcie@...12000 {
> >> compatible = "brcm,iproc-pcie";
> >> reg = <0x18012000 0x1000>;
> >>
> >> + interrupt-controller;
> >
> > How is this a fix? This doesn't even work before v5.16 with commit
> > 041284181226 ("of/irq: Allow matching of an interrupt-map local to an
> > interrupt controller").
>
> What is the path forward? I suppose I could make the
> interrupt-controller property not required for this controller but then
> the default interrupt-controller schema is not terribly happy about
> seeing an interrupt-map/interrupt-map-mask properties without
> interrupt-controller.
There's certainly no requirement for having 'interrupt-controller'.
What error are you getting?
Rob
Powered by blists - more mailing lists