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 08:58:33 +0100
From:	Marc Zyngier <marc.zyngier@....com>
To:	Mason <slash.tmp@...e.fr>
Cc:	Sebastian Frias <sf84@...oste.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Grygorii Strashko <grygorii.strashko@...com>,
	Mans Rullgard <mans@...sr.com>
Subject: Re: Using irq-crossbar.c

On 12/06/16 14:50, Mason wrote:
> On 12/06/2016 12:00, Marc Zyngier wrote:
> 
>> Mason wrote:
>>
>>> The problem with some Linux APIs is that they're logical and obvious
>>> to people who've been using them for years. For newcomers, it's not
>>> always so obvious.
>>>
>>> In this specific instance, the problem statement seems rather simple,
>>> on the surface. An interrupt controller, X=0..127 lines in, Y=0..23
>>> lines out (connected to GIC interrupt lines 0..23) and "all" we need
>>> is a way to map Xs to Ys.
>>>
>>> As a first order approximation, it's enough to map all Xs to 0.
>>> And provide a way for the kernel to check the registers containing
>>> the bit-vectors indicating which interrupt(s) fired.
>>
>> If that's what your hardware is, then you are taking the wrong
>> approach. The irq-crossbar driver does not do that at all: it has x
>> inputs and y outputs, but connects exactly *one input to one output*.
>> No multiplexing.
> 
> Connecting one input to one output is possible iff x=y right?
> (In other words, a bijection.)

It is *always* possible to connect anything to anything else. You were
assuming that this particular driver was fitting your particular case,
and it is obvious that it is not (iow: the crossbar transformation
cannot be surjective).

>> And the hierarchical domain infrastructure enforces a similar property:
>> a Linux interrupt is dealt with at each level of the hierarchy without
>> multiplexing: the "irq" is the same, while the "hwirq" varies to
>> reflect the "input pin" for a given interrupt controller.
>>
>> In your particular case, you have an evolved chained interrupt
>> controller, and nothing else.
> 
> Is it possible to support such an "evolved chained intc" through DT only,
> or does it require a few function calls from driver code?

There is no such thing as "DT only". You will have to do some actual
irqchip development.

>>>> - You've changed the default interrupt controller to be your crossbar.
>>>>   Which means that all the sub-nodes are inheriting it. Have you
>>>>   checked that this was valid for all of these nodes?
>>>
>>> I'm not sure I follow. All platform interrupts flow into the platform
>>> controller. Maybe other platforms have more complex setups, with
>>> several cascaded controllers?
>>
>> Most embedded platforms do.
> 
> My imagination is lacking, I don't see why it needs to be more
> complex than N platform input lines, and M output lines feeding
> into the GIC (with M <= N)

It is not more complex. It is different.

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