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

Powered by blists - more mailing lists