Re: fixup_bigphys_addr and ioremap64 question

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

> > 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:
> 
> It's in arch/ppc/syslib/44x_common.c and it's used to trap the least
> significant 32 bits of an address and set the right ERPN for io space on
> 44x.  Something like that might be needed when 44x merges to
> arch/powerpc.

Well, my point is that since nowadays we have 64 bits struct resource
and 64 bits phys_addr_t passed to ioremap, do we still need that ? In
fact, in my upcoming patch merging io.h for 32 and 64 bits in
asm-powerpc, I've simply removed that hook and ioremap64 :-) I can add
it back still, but so far, I yet have to be convinced there is still a
good reason for that hook.

Ben.