[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=Uf80P0_aOJw5NMd_oNm5fd8etXnM7m03ogUo7_Kk9G-A@mail.gmail.com>
Date: Fri, 11 Sep 2020 08:30:48 -0700
From: Doug Anderson <dianders@...omium.org>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: satya priya <skakit@...eaurora.org>,
Matthias Kaehlcke <mka@...omium.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andy Gross <agross@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
Akash Asthana <akashast@...eaurora.org>,
Roja Rani Yarubandi <rojay@...eaurora.org>,
msavaliy@....qualcomm.com
Subject: Re: [PATCH V5 2/4] arm64: dts: qcom: sc7180: Add necessary pinctrl
and interrupt config for BT UART
Hi,
On Fri, Sep 11, 2020 at 6:52 AM Bjorn Andersson
<bjorn.andersson@...aro.org> wrote:
>
> > > > &uart3 {
> > > > + pinctrl-names = "default", "sleep";
> > > > + pinctrl-1 = <&qup_uart3_sleep>;
> > > > + interrupts-extended = <&intc GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
> > > > + <&tlmm 41 IRQ_TYPE_EDGE_FALLING>;
> > >
> > > You need a:
> > >
> > > /delete-property/interrupts;
> > >
> > > ...or, alternatively, a patch before this one that converts all the
> > > UARTs in sc7180 to just use interrupts-extended.
> > >
> >
> > Sure, I will add this. But I think when both are added,
> > "interrupts-extended" will get priority as per [1] and there wouldn't be any
> > problem.
> >
>
> You're indeed correct, please stick with what you have.
IMO this is ugly, but I won't fight too hard on it if you guys really
want to do it that way. Reading the documentation it sounds as if
allowing for both is intended to be used in cases where the same
device tree might be used on old software (that didn't understand
interrupts-extended) and on new software (that does). The
interrupts-extended property by far predates any sc7180 support,
though, so I can't imagine anyone really needing to use that these
days. Is it really that bad to add the /delete-property/ to end up
with a cleaner final device tree?
-Doug
Powered by blists - more mailing lists