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