netdev - Re: Keystone 2 boards boot failure

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]

Date:	Wed, 03 Feb 2016 21:41:59 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Murali Karicheri <m-karicheri2@...com>
Cc:	Grygorii Strashko <grygorii.strashko@...com>,
	"Franklin S Cooper Jr." <fcooper@...com>, netdev@...r.kernel.org,
	w-kwok2@...com, davem@...emloft.net
Subject: Re: Keystone 2 boards boot failure

On Wednesday 03 February 2016 11:41:40 Murali Karicheri wrote:
> > 
> > This looks wrong: I was getting the build warnings originally
> > because of 64-bit dma_addr_t, and that should be the only way that
> > this driver can operate, because in some configurations on keystone
> > there is no memory below 4GB, and there is no dma-ranges property
> > in the DT that shifts around the start of the DMA addresses.
> Arnd,
> 
> Why do think so? I see in arch/arm/boot/dts/keystone.dtsi
> 
>         soc {
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 compatible = "ti,keystone","simple-bus";
>                 interrupt-parent = <&gic>;
>                 ranges = <0x0 0x0 0x0 0xc0000000>;
>                 dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
> 
> AFAIK, On Keystone, dma address is 32 bit and Physical DDR address is
> 64 bit (actually 36 bit, LPAE address). The conversion happens based on
> pfn_offset which is calculated based on the above dma-range property.

My mistake, see my other reply.
 


	Arnd