linux-kernel - Re: [RFC PATCH v1] irqchip: add support for SMP irq router

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:	Thu, 7 Jul 2016 13:42:36 +0100
From:	Marc Zyngier <marc.zyngier@....com>
To:	Sebastian Frias <sf84@...oste.net>,
	Jason Cooper <jason@...edaemon.net>
Cc:	Mason <slash.tmp@...e.fr>, LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH v1] irqchip: add support for SMP irq router

On 07/07/16 13:16, Sebastian Frias wrote:
> Hi Marc,
> 
> On 07/06/2016 03:50 PM, Marc Zyngier wrote:
>>> I think that's where part the misunderstanding comes from.
>>> IMHO the output line is not a direct function of the input line.
>>> Any of the 64 IRQ lines entering the "old controller" (irq-tango.c) can be
>>> routed to any of its 3 outputs.
>>
>> Then the current DT binding isn't properly describing the HW.
> 
> Ok, thanks, so it is not a good example then.
> 
>>> In a nutshell:
>>> - "old controller": routes [0...N] => GIC inputs [2...4]
>>> - "new controller": routes [0...M] => GIC inputs [0...23]
>>>
>>> So, when we think about it, if the "new DT" specified 24 domains, it would
>>> be equivalent of the "old DT" with 3 domains, right?
>>
>> Indeed, but I consider the "old" binding to be rather misleading. It
>> should have been described as a router too, rather than hardcoding
>> things in DT. Granted, it doesn't matter much when you only have 3
>> possible output lines. But with 24 outputs, that becomes much more relevant.
> 
> I see.
> 
>>> So, putting aside routing considerations and the discussion above, I think
>>> a simpler question is: if the domains should not be described in the DT,
>>> how can we define the IRQ sharing in the DT?
>>
>> You could have a set of sub-nodes saying something like this:
>>
>> 	mux-hint0 {
>> 		inputs = <1 45 127>;
>> 	}
>>
>> 	mux-hint1 {
>> 		inputs = <2 33>;
>> 	}
>>
>> (or maybe you can have that as direct properties, but you get the idea).
>> Here, you have two output pins dedicated to muxed interrupts (assuming
>> they are all level interrupts), and the last 22 can be freely allocated
>> as direct routes.
>>
> 
> Ok, I'll try to do that.
> So, aside from the DT issues (that is, that it is describing domains),
> would it be ok to create a domain for each of the outputs?
> 
> Because I was looking at:
> - Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt
> - drivers/irqchip/exynos-combiner.c
> - arch/arm/boot/dts/exynos4210.dtsi
> 
> and what I see is that the DT basically list all outputs [0...15] connected
> to the parent interrupt controller, although the driver does not creates
> separate domains, just one. Then it attaches a chained handler for each of
> the outputs. On the .map callback it attaches a irqchip to the domain.
> 
> There is also:
> - Documentation/devicetree/bindings/arm/omap/crossbar.txt
> - drivers/irqchip/irq-crossbar.c
> - arch/arm/boot/dts/dra7.dtsi
> 
> This one creates a domain hierarchy linked to the parent domain and uses
> irq_domain_alloc_irqs_parent() and irq_domain_set_hwirq_and_chip() to attach
> a irqchip to the domain on the .alloc callback.
> 
> Both use a single domain, as opposed to irq-tango.c which creates 3 domains.
> Right now irq-tango_v2.c is supposed to create one domain per output (if
> so the DT says)
> Are there guidelines regarding that?

The sensible thing would be to have one domain per output that muxes
inputs, and a hierarchical domain for all the other inputs (which are
mapped 1:1 with their output).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...