linux-kernel - RE: [PATCH v2 2/2] irqchip: Add support for Renesas RZ/N1 GPIO interrupt multiplexer

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: <TY1PR01MB17691CBAA81188A9D13D0576F5C50@TY1PR01MB1769.jpnprd01.prod.outlook.com>
Date:   Thu, 8 Nov 2018 15:37:19 +0000
From:   Phil Edworthy <phil.edworthy@...esas.com>
To:     Marc Zyngier <marc.zyngier@....com>, Rob Herring <robh@...nel.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 2/2] irqchip: Add support for Renesas RZ/N1 GPIO
 interrupt multiplexer

Hello Marc,

On 06 November 2018 13:16 Phil Edworthy wrote:
> On 31 October 2018 15:39, Phil Edworthy wrote
> > On 31 October 2018 15:31, Marc Zyngier wrote:
> > > On 31/10/18 15:09, Phil Edworthy wrote:
> > > > On 31 October 2018 08:02, Marc Zyngier wote:
> > > >> On Tue, 30 Oct 2018 10:44:38 +0000, Phil Edworthy wrote:
> > > >>>
> > > >>> On RZ/N1 devices, there are 3 Synopsys DesignWare GPIO blocks
> > > >>> each configured to have 32 interrupt outputs, so we have a total
> > > >>> of 96 GPIO interrupts. All of these are passed to the GPIO IRQ
> > > >>> Muxer, which selects
> > > >>> 8 of the GPIO interrupts to pass onto the GIC. The interrupt
> > > >>> signals aren't latched, so there is nothing to do in this driver
> > > >>> when an interrupt is received, other than tell the corresponding
> > > >>> GPIO
> > block.
> <snip>
> 
> > > There are two cases:
> > > 1) there is 1:1 mapping between a used input and an output, leaving
> > > some input unused
> > > 2) there is an n:1 mapping between input and output, and all the
> > > input can be used at any given time
> > >
> > > If what you have is (1), you need to implement an hierarchy.
> > > If what you have is (2), you need to implement a chained controller.
> > >
> > > (1) requires you to revisit this driver, making it a lot more like
> > > ti's irq-crossbar
> > > (2) requires you to actually do some decoding in the chained handler
> > >
> > > I believe you're in configuration (1). Am I right?
> > Right, it's a 1:1 mapping. The information about which input to be
> > used needs to be specified in dt.
> > I didn’t think I could implement a hierarchy that didn’t mask the
> > interrupts, so I need to go back over that and look again...
> 
> Ok, I have changed the driver to implement a hierarchy, i.e.
> call irq_domain_create_hierarchy() in probe, call
> irq_domain_set_hwirq_and_chip() and irq_domain_alloc_irqs_parent() in
> the irq_domain_ops.alloc function.

I suspect that I went in the wrong direction yet again...
After looking at Rob H's email again, I am now of the opinion that this
hardware, and the way to handle it, is very similar to PCIe MSI.

A cutdown DT looks like this:
	interrupts =
		<GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
		<GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
	#interrupt-cells = <1>;
	#address-cells = <0>;
	interrupt-map-mask = <127>;
	interrupt-map =
		/* gpio2a 24, pin 146: ETH Port 1 IRQ */
		<88 &gic GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
		/* gpio2a 26, pin 148: Touchscreen_IRQ */
		<90 &gic GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;

The only issue is that I can't see how to get the first element of each
interrupt-map entry in the driver. The driver needs to know that input
interrupt hwirq 88 corresponds to GIC_SPI 103, and 90 to GIC_SPI 104.

Thanks for your time & patience,
Phil