lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 17 Oct 2020 14:08:04 +0200
From:   Heiko Stübner <heiko@...ech.de>
To:     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,
        Krzysztof Kozlowski <krzk@...nel.org>,
        jagan@...rulasolutions.com
Subject: Re: [PATCH v2 1/2] ARM: dts: rk3188: correct interrupt flags

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.


Heiko



Powered by blists - more mailing lists