From mboxrd@z Thu Jan 1 00:00:00 1970 From: nico@fluxnic.net (Nicolas Pitre) Date: Mon, 26 Sep 2011 19:01:22 -0400 (EDT) Subject: Pull request: removal of most instances of mach/memory.h In-Reply-To: <20110926223810.GA23680@n2100.arm.linux.org.uk> References: <20110926131524.GJ22455@n2100.arm.linux.org.uk> <20110926191055.GP22455@n2100.arm.linux.org.uk> <20110926223810.GA23680@n2100.arm.linux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 26 Sep 2011, Russell King - ARM Linux wrote: > On Mon, Sep 26, 2011 at 04:00:11PM -0400, Nicolas Pitre wrote: > > On Mon, 26 Sep 2011, Russell King - ARM Linux wrote: > > > > > On Mon, Sep 26, 2011 at 10:33:28AM -0400, Nicolas Pitre wrote: > > > > ARM: mach-ep93xx: remove mach/memory.h and Kconfig selection of SDRAM bank > > > > > > Are you planning to totally kill off ZBOOT_ROM too? Because removing > > > the zreladdr stuff is doing exactly that. > > > > It looks like ZBOOT_ROM is not used on that platform at all. However, > > the ability to have a single defconfig and binary for the whole platform > > is something that the mach-ep93xx maintainers are looking for. Having > > ZBOOT_ROM depend on and use CONFIG_PHYS_OFFSET would probably makes > > sense eventually. > > You miss the point. Removing zreladdr actively _prevents_ anyone from > then choosing to build a kernel with ZBOOT_ROM enabled targetted for one > platform if that's what they want, because the decompressor then loses > the information it needs to properly locate the kernel. Sure. My point is that ZBOOT_ROM should eventually be coupled with CONFIG_PHYS_OFFSET to derive the zreladdr value. Like for XIP_KERNEL, there is no real point having ZBOOT_ROM when ARM_PATCH_PHYS_VIRT is set, and when not set we have the equivalent zreladdr information elsewhere already. Nicolas