On Wed, 2016-02-10 at 05:20 +0000, york sun wrote:
On 02/09/2016 09:10 PM, Scott Wood wrote:
On Wed, 2016-02-10 at 02:30 +0000, york sun wrote:
<snip>
Aneesh and Scott,
I need to revisit this patch. Would it be better to change it as below?
+#if defined(CONFIG_PHYS_64BIT) && !defined(CONFIG_ARM64) +typedef unsigned long long dma_addr_t; +typedef unsigned long long phys_addr_t; +typedef unsigned long long phys_size_t; +#else +/* DMA addresses are 32-bits wide */ typedef u32 dma_addr_t;
typedef unsigned long phys_addr_t; typedef unsigned long phys_size_t; +#endif
I am debugging another patch and found changing phys_addr_t makes some trouble for ARM64, especially to mix with ulong.
What sort of trouble is it causing? And why would you mix it with ulong?
I am debugging this patch http://patchwork.ozlabs.org/patch/514590/. ulong is used a lot for image related calls. I tried to change to phys_addr_t, but only buried myself even deeper. Basically I am battling on three sides
- All 32-bit SoCs should continue to work without using 64-bit variables
for addresses. 2. 64-bit SoCs such as ARMv8 will support FIT with addresses beyond 32 bits. 3. Host tool such as mkimage should work on both 32- and 64-bit host OS.
Any suggestion is welcomed.
Is there any situation where we'd support loading images to addresses that don't fit in ulong? Why do you need to switch it to phys_addr_t?
mkimage is another matter -- since it could be generating images for any target, it should be using a fixed 64-bit type for internally representing target addresses. Not ulong and not phys_addr_t (which shouldn't exist in userspace).
In any case, the answer isn't to undo this patch or make an exception for ARM64.
-Scott