fixup_bigphys_addr and ioremap64 question

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

While merging io.h between 32 and 64 bits arch/powerpc, I stumbled upon
this little gem :-)

So we have these:

 - If CONFIG_PHYS_64BIT is not set, nothing special. phys_addr_t is
defined to be 32 bits.

 - If it is set however, we have phys_addr_t defined to be 64 bits in
asm-ppc/mmu.h. 

So why do we have both ioremap and ioremap64 knowing that the former is
defined to take a phys_addr_t argument ?

Currently, we have both, with the only difference being that ioremap
calls ioremap64 but also passes the argument through a
fixup_bigphys_addr() function first.

It took me a while to find it ... it's not defined in generic code but
in platform code (ugh !). In fact, the only version of it we have in
arch/powerpc is in the 85xx support and does:

phys_addr_t fixup_bigphys_addr(phys_addr_t addr, phys_addr_t size)
{
	return addr;
};

So here's my question: Is it, as I think, some old mecanism that was
useful when ioremap didn't take a phys_addr_t argument and resources
didn't have 64 bits fields and thus we had a way to "remap" IOs from a
32 bits space into a 64 bits space in a platform specific way ?

Now, the big question is: do we still need that ?

If, as I expect, the answer is no, then I'll just remove it. I'll also
remove ioremap64 from arch/powerpc since ioremap can take a 64 bits
value directly.

Now, if the answer is yes, then I'll turn it into a ppc_md. call since
it its current form, it's just broken.

Ben.