netdev - Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190610083012.GV5447@atomide.com>
Date:   Mon, 10 Jun 2019 01:30:12 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     Kalle Valo <kvalo@...eaurora.org>
Cc:     Eugeniu Rosca <erosca@...adit-jv.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Simon Horman <horms+renesas@...ge.net.au>,
        "David S. Miller" <davem@...emloft.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Spyridon Papageorgiou <spapageorgiou@...adit-jv.com>,
        Joshua Frkuska <joshua_frkuska@...tor.com>,
        "George G . Davis" <george_davis@...tor.com>,
        Andrey Gusakov <andrey.gusakov@...entembedded.com>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Eugeniu Rosca <roscaeugeniu@...il.com>, eyalr@...com
Subject: Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically
 inverted IRQ

Hi,

* Kalle Valo <kvalo@...eaurora.org> [190610 07:01]:
> Eugeniu Rosca <erosca@...adit-jv.com> writes:
> 
> > The wl1837mod datasheet [1] says about the WL_IRQ pin:
> >
> >  ---8<---
> > SDIO available, interrupt out. Active high. [..]
> > Set to rising edge (active high) on powerup.
> >  ---8<---
> >
> > That's the reason of seeing the interrupt configured as:
> >  - IRQ_TYPE_EDGE_RISING on HiKey 960/970
> >  - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
> >
> > We assert that all those platforms have the WL_IRQ pin connected
> > to the SoC _directly_ (confirmed on HiKey 970 [2]).
> >
> > That's not the case for R-Car Kingfisher extension target, which carries
> > a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> > between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> > reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> > configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> > IRQ_TYPE_LEVEL_LOW.
> >
> > Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> > support platform dependent interrupt types") made a special case out
> > of these interrupt types. After this commit, it is impossible to provide
> > an IRQ configuration via DTS which would describe an inverter present
> > between the WL18* chip and the SoC, generating the need for workarounds
> > like [3].
> >
> > Create a boolean OF property, called "invert-irq" to specify that
> > the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
> >
> > This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> > the DTS configuration [4] combined with the "invert-irq" property.
> >
> > [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> > [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> > [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch
> > [4] https://patchwork.kernel.org/patch/10895879/
> >     ("arm64: dts: ulcb-kf: Add support for TI WL1837")
> >
> > Signed-off-by: Eugeniu Rosca <erosca@...adit-jv.com>
> 
> Tony&Eyal, do you agree with this?

Yeah if there's some hardware between the WLAN device and the SoC
inverting the interrupt, I don't think we have clear a way to deal
with it short of setting up a separate irqchip that does the
translation.

But in some cases we also do not want to invert the interrupt, so
I think this property should take IRQ_TYPE_EDGE_RISING and
IRQ_TYPE_EDGE_RISING values to override the setting for
the WLAN end of the hardware?

Let's wait a bit longer for comments from Eyal too.

Regards,

Tony