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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdX6s1yYpwVoRiQYr2F5MTKqgSFLzVRniw6QYHgUmG7KBA@mail.gmail.com>
Date:	Thu, 22 May 2014 09:48:00 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Jonas Bonn <jonas@...thpole.se>
Cc:	Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
	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 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.

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

Just my 2 c...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/