From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Date: Fri, 22 Aug 2014 10:29:32 +0200 Subject: [U-Boot] [PATCH 2/9] ARM: cache-cp15: Use unsigned long for address and size In-Reply-To: <53F4F3C3.4000809@wwwdotorg.org> References: <1408348852-30894-1-git-send-email-thierry.reding@gmail.com> <1408348852-30894-3-git-send-email-thierry.reding@gmail.com> <53F4F3C3.4000809@wwwdotorg.org> Message-ID: <20140822082931.GB24156@ulmo> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > > > >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: