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]

Message-ID: <575C304F.2070303@free.fr>
Date:	Sat, 11 Jun 2016 17:37:51 +0200
From:	Mason <slash.tmp@...e.fr>
To:	Marc Zyngier <marc.zyngier@....com>
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 11/06/2016 11:58, Marc Zyngier wrote:

> Mason wrote:
> 
>> I think Sebastian is even more baffled by the DT mess
>> (sorry, intricacies) than I am.
> 
> This mess is what has saved us from the apocalypse 5 years ago, and
> describing a complex system is not easy (what a surprise...).

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 you just want to apply recipes without understanding the underlying
> constraints, you're in for a lot of pain.

For example, the IRQ driver for Tango3/4 calls

irq_find_mapping
generic_handle_irq
irq_desc_get_handler_data
irq_desc_get_chip
chained_irq_enter/chained_irq_exit
irq_setup_alt_chip
irq_get_domain_generic_chip
irq_domain_add_linear
irq_alloc_domain_generic_chips
irq_set_chained_handler
irq_set_handler_data

Taking irq_find_mapping, I see that there's a short comment in
kernel/irq/irqdomain.c

/**
 * irq_find_mapping() - Find a linux irq from an hw irq number.
 * @domain: domain owning this hardware interrupt
 * @hwirq: hardware irq number in that domain space
 */

Is this Doxygen format? Is there a make target to generate
some documentation?

Other relevant resources, for my own reference:

https://www.kernel.org/doc/Documentation/IRQ-domain.txt
https://stackoverflow.com/questions/34371352/what-are-linux-irq-domains-why-are-they-needed
https://community.nxp.com/thread/332183

Are there other important kernel documentation?

>> The base file he was referring to is:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-common.dtsi
> 
> I know which file that is, it is mentioned in the diff. I was merely
> trying to point out the glaring mistakes that could be enough for a
> interrupt controller hierarchy to be completely non-functional:

Only the name of the file was provided, not the path. I was not aware
that you already knew where to find it. I made no claim whatsoever on
the implementation. In fact, I agree with everything Lennart wrote.

> - Your crossbar doesn't have a #interrupt-cells property. How do you
>   expect the interrupt specifiers to be interpreted?

Why do "fundamental" DT properties start with hash?

> - 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?

Have a nice week end :-)