linux-kernel - Re: [PATCH v2 3/6] ARM: dts: Device tree for AXM55xx.

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: <CACRpkdbU6UashxCuPMDjEB_nbB=mXicGpjJy=HGC6r3qfxCtVQ@mail.gmail.com>
Date:	Thu, 24 Apr 2014 15:24:14 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Anders Berg <anders.berg@....com>
Cc:	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	Mike Turquette <mturquette@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Russell King <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/6] ARM: dts: Device tree for AXM55xx.

On Thu, Apr 24, 2014 at 12:44 PM, Anders Berg <anders.berg@....com> wrote:

> Add device tree for the Amarillo validation board with an AXM5516 SoC.
>
> Signed-off-by: Anders Berg <anders.berg@....com>
(...)

> +                       timer0: timer@...0091000 {
> +                               compatible = "arm,sp804", "arm,primecell";
> +                               reg = <0x20 0x10091000 0 0x1000>;
> +                               interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
> +                               clocks = <&clk_per>;
> +                               clock-names = "apb_pclk";
> +                               status = "okay";
> +                       };
> +
> +                       gpio0: gpio@...0092000 {
> +                               #gpio-cells = <2>;
> +                               compatible = "arm,pl061", "arm,primecell";
> +                               gpio-controller;
> +                               reg = <0x20 0x10092000 0x00 0x1000>;
> +                               interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
> +                                            <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> +                               clocks = <&clk_per>;
> +                               clock-names = "apb_pclk";
> +                               status = "disabled";
> +                       };

One interrupt per CPU core?

The drivers for these blocks will really just grab the first IRQ and
then I guess they
will only be able to execute on CPU0.

It's definately correct to list all the IRQs here, but how do you envision
the drivers making use of them in the long run?

Yours,
Linus Walleij
--
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/