On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote: > On Wed, Apr 11, 2012 at 04:52:32PM +0100, Russell King - ARM Linux wrote: > > On Wed, Apr 11, 2012 at 10:44:22AM -0400, Nicolas Pitre wrote: > > > On Wed, 11 Apr 2012, Will Deacon wrote: > > > > > > > If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE > > > > kernel then we will hang early during boot since the memory bank will > > > > have wrapped around to zero. > > > > > > > > This patch truncates memory banks for !LPAE configurations when the end > > > > address is not representable in 32 bits. > > > > > > > > Cc: Nicolas Pitre <nico@xxxxxxxxxxx> > > > > Signed-off-by: Will Deacon <will.deacon@xxxxxxx> > > > > > > Acked-by: Nicolas Pitre <nico@xxxxxxxxxx> > > > > > > Now what if start = 1G and size = 5G? The size variable is an unsigned > > > long, meaning that right now the size might be truncated to 1G. > > > > There's a solution to that which is quite easy to do: convert the bank > > information to PFNs instead of addresses. That will probably eliminate > > some corner cases with partial pages which would be desirable too. > > Of course, what prevents us doing that conversion sanely is all the > shite platform code doing crap stuff like this: > > arch/arm/mach-msm/board-halibut.c: mi->bank[0].start = PHYS_OFFSET; > arch/arm/mach-msm/board-halibut.c: mi->bank[0].size = (101*1024*1024); > > which I went through everything a few years ago and eliminated all this > crap. It's back now. Sod it, we'll stick with the current 4GiB limited > way as long as we have platform maintainers who do this kind of crappy > hack. I'm not sure there are even any working "halibut" targets (MSM7201 SURF). It wasn't a generally available target. I think the only in-use fish target is trout (HTC Dream). Although, it seems that every time I think this, someone will speak up about one of these targets. > While here, I propose to delete these: > > arch/arm/mach-msm/board-mahimahi.c: mi->bank[0].start = PHYS_OFFSET; > arch/arm/mach-msm/board-mahimahi.c: mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET); > arch/arm/mach-msm/board-mahimahi.c: mi->bank[0].size = (219*1024*1024); > arch/arm/mach-msm/board-mahimahi.c: mi->bank[1].start = MSM_HIGHMEM_BASE; > arch/arm/mach-msm/board-mahimahi.c: mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE); > arch/arm/mach-msm/board-mahimahi.c: mi->bank[1].size = MSM_HIGHMEM_SIZE; > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].start = PHYS_OFFSET; > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET); > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].size = (84*1024*1024); > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].size = (101*1024*1024); > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].size = (101*1024*1024); > > because they haven't been buildable since 7th May 2010 (that's 23 months > ago), and no one has reported any build errors with them. They're only > receiving updates from other sweeps and nothing more. This all means no > one is even attempting to build this code. It's pointless having > unbuildable code in the kernel, and it's nothing more than a useless > maintanence burden. I don't think these were ever built. They were never added to the Makefiles. Patch to follow. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
