[U-Boot] [PATCH 2/3][v3] Data types defined for 64 bit physical address

[Scott Wood]

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