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]
Date:	Mon, 14 Nov 2011 08:20:38 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Peter De Schrijver <pdeschrijver@...dia.com>,
	Rob Herring <robherring2@...il.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Colin Cross <ccross@...roid.com>,
	Olof Johansson <olof@...om.net>,
	Russell King <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v4 01/10] arm/tegra: initial device tree for tegra30

Peter De Schrijver wrote at Monday, November 14, 2011 9:07 AM:
> On Mon, Nov 14, 2011 at 04:41:13PM +0100, Rob Herring wrote:
> > On 11/14/2011 09:25 AM, Peter De Schrijver wrote:
> > > On Sat, Nov 12, 2011 at 04:26:30AM +0100, Rob Herring wrote:
> > >> On 11/11/2011 05:22 AM, Peter De Schrijver wrote:
> > >>> This patch adds the initial device tree for tegra30
...
> > >>> +	interrupt-parent = <&intc>;
> > >>> +
> > >>> +	intc: interrupt-controller@...41000 {
> > >>> +		compatible = "nvidia,tegra30-gic", "nvidia,tegra20-gic";
> > >>> +		interrupt-controller;
> > >>> +		#interrupt-cells = <1>;
> > >>
> > >> Is the Tegra GIC really different from a standard A9 gic? You need to
> > >> update to use the gic binding. The cells should be 3 for example.
> > >
> > > It has an extra 'legacy' interrupt controller like tegra20 has. This is used
> > > when waking up the CPU from power off mode.
> >
> > Although that is probably not part of the GIC h/w (i.e. at a different
> > address) and should be described in the dts separately. That doesn't
> > change the GIC binding or the fact that you are using
> > arch/arm/common/gic.c though. Whether you have a different compatible
> > string or not is not really the issue. That can already be supported if
> > necessary. The issue is you are not using the existing GIC binding as a
> > starting point and that has implications on every node using a GIC
> > interrupt.
> >
> 
> The GIC is the same as the one used on tegra20. So I copied the binding from
> tegra20.dtsi. Is that one wrong too then?

The existing Tegra20 .dtsi file doesn't use the new GIC bindings yet
either, which as Peter points out is where he copied the GIC node from.
My suggestion is that we merge the Tegra30 .dtsi as shown above, and then
do a single pass to convert both tegra20.dtsi and tegra30.dtsi over to the
new GIC binding, to prevent blocking the merge of tegra30.dtsi on the GIC
binding rework. Does that sound fair?

-- 
nvpublic

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ