linux-kernel - Re: [PATCH v4 1/5] zynq: use GIC device tree bindings

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: <20121027144253.GC5190@beefymiracle.amer.corp.natinst.com>
Date:	Sat, 27 Oct 2012 09:42:53 -0500
From:	Josh Cartwright <josh.cartwright@...com>
To:	Michal Simek <michal.simek@...inx.com>
Cc:	"arm@...nel.org" <arm@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	John Linn <linnj@...inx.com>,
	Nick Bowler <nbowler@...iptictech.com>
Subject: Re: [PATCH v4 1/5] zynq: use GIC device tree bindings

On Sat, Oct 27, 2012 at 02:06:45PM +0000, Michal Simek wrote:
[...]
> I am not big fan to use dtsi solution because dts can be simple generated directly
> From Xilinx design tool based on your hw design. That's why I can't see any benefit
> To have dtsi file.

Can I ask you to reconsider?  We, for example, don't make any use of the
Xilinx dev tools to generate our device trees.  Having a dtsi allows for
easy extension of the zynq-7000 platform for our boards, without having
to carry duplicate data.

Is it going to be expected that users building kernels for their zynq
targets have access to the Xilinx EDK?

> > Would you like for me to pull this into v5, or spin up a separate patch series?
>
> Definitely not. I have checked patches but haven't got it work on the zc702.
> Not sure if you have run it on real hw or just on the qemu as you have mentioned
> In 5/5.

You're likely running into the issue Nick has identified in the thread
for patch 5 where the chosen virtual address for the uart doesn't seem
to work: http://www.spinics.net/lists/arm-kernel/msg203141.html

We haven't yet identified the root cause; any insight you can provide
here would be beneficial.

Otherwise, I'm considering reworking patch 5 to move the uart mapping to
a known working location.

Thanks,

   Josh

Content of type "application/pgp-signature" skipped