[U-Boot] [PATCH 2/9] ARM: cache-cp15: Use unsigned long for address and size

[Thierry Reding <thierry.reding@gmail.com>]

On Wed, Aug 20, 2014 at 01:15:15PM -0600, Stephen Warren wrote:
> On 08/18/2014 02:00 AM, Thierry Reding wrote:
> >From: Thierry Reding <treding@nvidia.com>
> >
> >size is always non-negative, so it should be unsigned, whereas the
> >address and size can be larger than 32 bit on 64-bit architectures.
> >Change the mmu_set_region_dcache_behaviour() to use these types in
> >anticipation of making the API available on other architectures.
> 
> >diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> 
> >-void mmu_set_region_dcache_behaviour(u32 start, int size,
> >+void mmu_set_region_dcache_behaviour(unsigned long start, unsigned long size,
> >  				     enum dcache_option option);
> 
> If we were to use LPAE on a 32-bit system, physical addresses could be more
> than 32-bit. That would imply we should create a physaddr_t type rather than
> relying on unsigned long. Still, I suppose since U-Boot just maps RAM (and
> everything else) 1:1, we'd never use RAM beyond 4GiB, so LPAE actually isn't
> that interesting...

Interestingly there is already a phys_addr_t type defined (as opposed to
Linux it's defined in arch/*/include/asm/types.h). It doesn't currently
take into account things like LPAE, but then again there's no standard
configuration option to select that (Linux has CONFIG_PHYS_ADDR_T_64BIT
for this). CONFIG_PHYS_64BIT seems to come close, but it's currently
only defined by true 64-bit architectures.

I took a stab at unifying the various definitions in linux/types.h, but
that resulted in all kinds of weird build errors all over the place, so
at some point I gave up and kept the definitions as they are. Still, for
this series I've tried to use the existing phys_addr_t where appropriate
so it should just be a matter of properly redefining in for LPAE if
support for it ever gets added.

I've refrained from using phys_size_t since I don't see why it would be
useful and instead used size_t consistently where a size is involved. If
anyone feels strongly about using phys_size_t I can use it instead,
though.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140822/f581a37f/attachment.pgp>