linux-kernel - Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

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]

Date:   Mon, 30 Sep 2019 19:54:28 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "rayagonda.kokatanur@...adcom.com" <rayagonda.kokatanur@...adcom.com>,
        "bcm-kernel-feedback-list@...adcom.com" 
        <bcm-kernel-feedback-list@...adcom.com>,
        "li.jin@...adcom.com" <li.jin@...adcom.com>,
        "sbranden@...adcom.com" <sbranden@...adcom.com>,
        "rjui@...adcom.com" <rjui@...adcom.com>
Cc:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>
Subject: Re: Problem sharing interrupts between gpioa and uart0 on Broadcom
 Hurricane 2 (iProc)



On 9/30/2019 7:33 PM, Chris Packham wrote:
> Hi,
> 
> We have a platform using the BCM53344 integrated switch/CPU. This is
> part of the Hurricane 2 (technically Wolfhound) family of devices.
> 
> Currently we're using pieces of Broadcom's "iProc" SDK based on an out
> of date kernel and we'd very much like to be running as close to
> upstream as possible. The fact that the Ubiquiti UniFi Switch 8 is
> upstream gives me some hope.

FYI, I could not get enough information from the iProc SDK to port (or
not) the clock driver, so if nothing else, that is an area that may
require immediate work (though sometimes fixed-clocks would do just fine).

> 
> My current problem is the fact that the uart0 interrupt is shared with
> the Chip Common A gpio block. When I have and interrupt node on the
> gpio in the device tree I get an init exit at startup. If I remove the
> interrupt node the system will boot (except I don't get cascaded
> interrupts from the GPIOs).
> 
> Looking at the pinctrl-nsp-gpio.c it looks as though I might be able to
> make this work if I can convince the gpio code to return IRQ_HANDLED or
> IRQ_NONE but I'm struggling against the fact that the pinctrl-iproc-
> gpio.c defers it's interrupt handing to the gpio core.

Not sure I follow you here, what part is being handed to gpiolib? The
top interrupt handler under nsp_gpio_irq_handler() will try to do
exactly as you described. In fact, there are other iProc designs where
"gpio-a" and another interrupt, arch/arm/boot/dts/bcm-nsp.dtsi is one
such example and I never had problems with that part of NSP.

> 
> Is there any way I can get the gpio core to deal with the shared
> interrupt?
-- 
Florian