linux-kernel - Re: Using irq-crossbar.c

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, 13 Jun 2016 13:59:42 -0400
From:	"Lennart Sorensen" <lsorense@...lub.uwaterloo.ca>
To:	Sebastian Frias <sf84@...oste.net>
Cc:	Marc Zyngier <marc.zyngier@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Grygorii Strashko <grygorii.strashko@...com>,
	Sricharan R <r.sricharan@...com>, Mason <slash.tmp@...e.fr>,
	Måns Rullgård <mans@...sr.com>
Subject: Re: Using irq-crossbar.c

On Mon, Jun 13, 2016 at 05:46:19PM +0200, Sebastian Frias wrote:
> My understanding of "hierarchical irq domains" is that it is useful when there are multiple stacked interrupt controllers.
> Also, the documentation says "the majority of drivers should use the linear map" (as opposed to the hierarchical one).
> 
> Maybe the definition of "interrupt controller" could benefit from some clarification, but my understanding is that, in our case, the GIC is the only interrupt controller (that's where the interrupt type must be set active_high/active_low/edge, etc.), in front of it, it happens to be a crossbar, that happens to be programmable, and that can be used to map any 128 line into any of 24 lines of the GIC (actually it is a many-to-many router, without any latching nor edge detection functionality)
> 
> Obviously, when the DT says that ethernet driver uses IRQ=120 (for example), the crossbar must be setup to route line 120 to one of the 24 lines going to the GIC.
> So a minimum of interaction between the GIC driver (and/or the Linux IRQ framework) and the driver programming the crossbar is required, and that's what we are trying to achieve.
> 
> Does that makes sense?

Well something has to tell the crossbar to map 120 to one of the 24.
Of course the driver for the device needs to be told to use the one of
the 24 it was mapped to.

As far as I recall the TI irq-crossbar allows you to specify in the DT
that you want to use a given input to the crossbar for a given device,
and it dynamically allocated a mapping to a free IRQ on the CPU and maps
it and the driver is told the correct interrupt to use for that device.
Pretty handy.  With older versions of the driver you had to setup all
the maps manually in the devicetree and manually assign the correct IRQ
to the driver, which was more error prone of course and a bit of a hassle.

-- 
Len Sorensen