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

Date:   Tue, 6 Nov 2018 13:15:35 +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

Hi Marc,

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've got a couple of issues that I hope you can provide some input on.

First is what to do with irqs that are input to this mux but not selected.
If I don't call irq_domain_set_hwirq_and_chip() and irq_domain_alloc_irqs_parent(),
it causes the driver for the hardware that generates these interrupts (in
this case, Synopsys dwapb_gpio) to throw an exception in
irq_set_chained_handler_and_data().
As a hack, I have simply used an unused output irq.

Second is specifying the output irqs. Currently, I specify them like this:
	interrupts =
		<GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
		<GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
		...
		<GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
However, I am only reading the property so I can pass the fwspec to
irq_domain_alloc_irqs_parent(). I am not using anything that ends up
in of_irq_parse_raw().

Rob H has previously said that I should use interrupt-map to describe the
relationship between the input and output irqs. Unfortunately, irq
hierarchy seems to be somewhat at odds with using interrupt-map.
Or at least, I can’t see how the two can be combined.

Your feedback on this is greatly appreciated!
Thanks
Phil