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] [day] [month] [year] [list]

Message-ID: <e2e887ae92b61b01eda02b53522b6b07935042ea.camel@alliedtelesis.co.nz>
Date:   Wed, 2 Oct 2019 21:15:49 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "rayagonda.kokatanur@...adcom.com" <rayagonda.kokatanur@...adcom.com>,
        "bcm-kernel-feedback-list@...adcom.com" 
        <bcm-kernel-feedback-list@...adcom.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "li.jin@...adcom.com" <li.jin@...adcom.com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "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 Tue, 2019-10-01 at 16:04 +1300, Chris Packham wrote:
> Hi Florian,
> 
> On Mon, 2019-09-30 at 19:54 -0700, Florian Fainelli wrote:
> > 
> > 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).
> 
> Setting a fixed clock seems to work for me. At least for now.
> 
> > 
> > > 
> > > 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.
> > 
> 
> nsp_gpio_probe() creates the irq domain directly and
> nsp_gpio_irq_handler() directly deals with sharing by returning
> IRQ_HANDLED or IRQ_NONE depending on whether it has a bit set.
> 
> iproc_gpio_probe() on the sets iproc_gpio_irq_handler() as the
> parent_handler and defers to gpiolib to deal with the irq domain etc.
> 
> I'm currently assuming this is why I can't have uart0 and gpio
> interrupts. But of course I could be completely wrong.
> 
> > > 
> > > Is there any way I can get the gpio core to deal with the shared
> > > interrupt?

I think at least part of my problem is that the iProc ChipCommonB
register layout is different to the iProc ChipCommonA. It's closer to
the NorthStar Plus but still different layout. I think I'll need to
write a new driver rather than trying to get pinctrl-nsp-gpio.c or
pinctrl-iproc-gpio.c to work.