Pull request: removal of most instances of mach/memory.h

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Mon, Sep 26, 2011 at 07:01:22PM -0400, Nicolas Pitre wrote:
> 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.

I strongly disagree on a technical point - ARM_PATCH_PHYS_VIRT and
ZBOOT_ROM are entirely separate options _technically_ - there is no
inter-dependence between them.  ZBOOT_ROM just needs to know where
to place the decompressed image, and once it knows that, the kernel
can discover the P:V translation all by itself.

Moreover, PHYS_OFFSET does *not* define where the kernel ends up.
Remember that we sometimes place the kernel 1MB + 32K into the
physical memory space - you can't encode that into CONFIG_PHYS_OFFSET
and hope that both PHYS_OFFSET and zreladdr end up at the right place.

So this is argument is actually highly flawed technically.  You're
trying to combine two things which are actually different.

Or are we now in the business of breaking old platforms?