linux-kernel - Re: [PATCH v2] openrisc: irq: use irqchip framework

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140521202330.GB14701@chokladfabriken.org>
Date:	Wed, 21 May 2014 23:23:31 +0300
From:	Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>
To:	Jason Cooper <jason@...edaemon.net>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>, linux@...ts.openrisc.net,
	jonas@...thpole.se
Subject: Re: [PATCH v2] openrisc: irq: use irqchip framework

On Wed, May 21, 2014 at 04:01:56PM -0400, Jason Cooper wrote:
> On Wed, May 21, 2014 at 10:50:57PM +0300, Stefan Kristiansson wrote:
> ...
> > I see two paths to go to get there though, and here's where I'd like some input.
> > 1) Define the three different implementations as seperate irqchips,
> >    with accompanying IRQCHIP_DECLARE.
> > 2) Add custom device-tree bindings and determine the chip type from that.
> > 
> > What would be the best choice here?
> > I think I'm leaning towards 1) and I have a tentative patch for that,
> > but I wanted to went the question before posting it.
> 
> Are there actually three IP blocks here that we may see separately
> somewhere else?
> 

Not exactly, the interrupt controller is embedded inside the OpenRISC cpu.
But, the interrupt controller can either be edge or level triggered
(and this is a fixed setting for the whole controller).
And in addition to that, there is one implementation of the interrupt controller
that have some additional quirks, like level interrupts need to be acked,
and the polarity of the ack signal is negated to what the specification says.

And there's no (sane) way to detect what kind of controller is implemented
in the cpu, so it has to be 'user-provided'
(read, provided from the device-tree).

Stefan
--
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/