[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJKOXPeX8su0dzHWRWUZfOdZaB5CXU1GpUOXg+pS7CQdX3XWOg@mail.gmail.com>
Date: Sat, 2 Apr 2022 18:49:05 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Heiko Stübner <heiko@...ech.de>
Cc: Rob Herring <robh+dt@...nel.org>, Johan Jonker <jbx6244@...il.com>,
Kever Yang <kever.yang@...k-chips.com>,
Vivek Unune <npcomplete13@...il.com>,
Alexis Ballier <aballier@...too.org>,
Jagan Teki <jagan@...rulasolutions.com>,
Anand Moon <linux.amoon@...il.com>,
linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, devicetree@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] ARM: dts: rk3188: correct interrupt flags
On Sat, 17 Oct 2020 at 14:08, Heiko Stübner <heiko@...ech.de> wrote:
>
> Hi,
>
> Am Freitag, 2. Oktober 2020, 18:11:28 CEST schrieb Krzysztof Kozlowski:
> > On Thu, Sep 17, 2020 at 08:52:10PM +0200, Krzysztof Kozlowski wrote:
> > > GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> > > These are simple defines so they could be used in DTS but they will not
> > > have the same meaning:
> > > 1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE
> > > 2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING
> > >
> > > Correct the interrupt flags without affecting the code:
> > > ACTIVE_HIGH => IRQ_TYPE_NONE
> > >
> > > Signed-off-by: Krzysztof Kozlowski <krzk@...nel.org>
> > >
> > > ---
> > >
> > > Not tested on HW.
> > >
> > > Changes since v1:
> > > 1. Correct title
> > > ---
> > > arch/arm/boot/dts/rk3188-bqedison2qc.dts | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > Hi,
> >
> > Any comments/review/testing from Heiko or other Rockchip folks? Shall I
> > cc here someone?
>
> I'm actually wondering about this ... I somehow remember writing a response,
> but don't see it in my history - so it might have gotten lost before I
> actually sent it.
>
> I think the biggest issue I have is that none of that is tested on any
> hardware and looking at other brcm wifi drivers in the kernel, the
> interrupt polarity seems to be all over the place, some set it high,
> some low and I even have seen edge triggers.
>
> As all changes are in regard to (copied) brcm wifi node, it would be
> really interesting to actually know what trigger is the right one.
>
> I've Cc'ed Jagan who I think has worked on an affected board,
> maybe he can check which trigger is correct.
Hi Heiko,
Nothing moved here since 2020 and the DTSes still have incorrect flags
for interrupts.
I can rebase and resend (although maybe it still applies cleanly), but
more important - is someone going to take this patch? or test it?
Best regards,
Krzysztof
Powered by blists - more mailing lists