linux-kernel - Re: [PATCH V3] irqchip: Add TB10x interrupt controller driver (2)

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, 3 Jun 2013 10:00:04 +0200
From:	Christian Ruppert <christian.ruppert@...lis.com>
To:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Thomas Gleixner <tglx@...utronix.de>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Pierrick Hascoet <pierrick.hascoet@...lis.com>
Subject: Re: [PATCH V3] irqchip: Add TB10x interrupt controller driver (2)

On Mon, Jun 03, 2013 at 11:03:13AM +0530, Vineet Gupta wrote:
> On 06/01/2013 04:31 PM, Christian Ruppert wrote:
> > On Fri, May 31, 2013 at 11:18:14PM +0100, Grant Likely wrote:
> >> On Fri, 31 May 2013 19:32:34 +0200 (CEST), Thomas Gleixner <tglx@...utronix.de> wrote:
> >>> On Fri, 31 May 2013, Christian Ruppert wrote:
> [...]
> >> The loop above is mapping each of the
> >> interrupt inputs on the parent controller so that each child controller
> >> can be chained to it as an input. I can't think of how else it could be
> >> set up with the current code if the drivers were kept separate.
> > This is exactly the intention. I haven't found an easier way to do this
> > either but I'm open to suggestions.
> 
> But the child intc must only uplink to one parent intc IRQ line. In that
> case why do we need to enumerate the rest of them in code. Is that a
> limitation of framework or the parent intc (with it's legacy domain
> instantiation) is not doing something correct.

You are right, it would have been possible to "merge" several interrupt
sources onto the same ARC input. This is done (where required) further
down the interrupt controller hierarchy, however, and the way our
hardware is designed is that every input line of the tb10x-ictl controls
a separate output line. Every one of these output lines is connected to
a different ARC interrupt input. tb10x-ictl does not "merge" several
interrupts:

                      ...
                   |
               3 --+ 3
                   |
               4 --+ 4
       +-----+     |
   5 --+.....+-----+ 5
       |tb10x|     |     ARC770
   6 --+.....+-----+ 6
       |-ictl|     |
   7 --+.....+-----+ 7
       |     |     |
   8 --+.....+-----+ 8
       |     |     |
         ...          ...

> [...]
> >> If I were working on this system I'd drop the
> >> snps,arc700-intc node entirely and have a single abilis,tb10x-intc that
> >> encapsulated the properties of both (you would of course want to share
> >> handler functions for the 'normal' inputs without the custom features).
> >> That would eliminate the goofyness of listing 27 separate interrupts in
> >> the abilis,tb10x-ictl interrupts property.
> > To complicate things even further, some ARC CPU built-in peripherals
> > (e.g. timers) generate interrupts directly to the ARC built-in interrupt
> > controller (without going through the TB10x front-end), hence the
> > "goofy" list of interrupts in the TB10x DT node.
> 
> But I presume that this is common-place for cascaded intc setups - some
> peripherals hooking up directly to topmost intc would be normal. But it
> seems I'm not as educated in area as I really should be.

Yep, that's completely normal. But it forces us to tell the driver which
ones of the interrupts it must manage and which ones it should ignore.

Greetings,
  Christian

-- 
  Christian Ruppert              ,          <christian.ruppert@...lis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pré-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/