linux-kernel - Re: [ORLinux] [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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 22 May 2014 22:58:12 +0300
From:	Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Jonas Bonn <jonas@...thpole.se>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Jason Cooper <jason@...edaemon.net>,
	linux <linux@...ts.openrisc.net>
Subject: Re: [ORLinux] [PATCH v2] openrisc: irq: use irqchip framework

On Thu, May 22, 2014 at 09:48:00AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 22, 2014 at 9:32 AM, Jonas Bonn <jonas@...thpole.se> wrote:
> > On 05/21/2014 09:50 PM, 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.
> >
> > I think 1) above is the way to go.  Something alone the lines of
> > "opencores,or1k-pic-level", "opencores,or1k-pic-edge", and
> > "opencores,or1200-pic".
> 
> Sounds fine to me. The only thing I'm still wondering about is whether
> to have both "opencores,or1k-pic-*" variants, or just ""opencores,or1k-pic"
> and an (optional) property for edge/level selection.
> 
> Is edge support planned to stay in future versions of the specifications?
> If not, go with the optional property to select edge.
> If yes, have two variants.
> 

There have been no discussion about removing the edge triggered options.

Adding an optional property would afaict in practice be option 2),
as we would need to add a custom device-tree binding for it.
There are the pre-existing 'flags' in the 'interrupts' binding,
but it has slighty different semantics, since it is per interrupt-line and
not per interrupt controller.
Besides, using that property would mean that we would need to change
#interrupt-cells from 1 to 2, which would break pre-existing device-tree
descriptions.

> > The first two match the behaviour of the or1k specification; the third
> > one, however, is really a misimplementation of the spec and is kind of
> > tied to the actual implementation of the OR1200... I wonder if we don't
> > need to version this one like we version the CPU identifier (*-rtlsvnXXXXX).
> 
> Is this planned to be fixed for OR1200?
> If yes, how? If this will be done by switching to the version that follows the
> or1k spec, the compatible value in DT can just be changed to one of the
> "opencores,or1k-pic-*" variants.
> 

I agree, I think the or1200-pic identifier is enough to mark the "special" pic.
If the or1200 would be fixed, it certainly be according to the or1k spec.
But, apart from the or1200 itself, there are other implementations
(e.g. mor1kx) that can be configured to be "or1200 pic compatible",
to enable them to be suitable as drop-in replacements.

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/