fixup_bigphys_addr and ioremap64 question

[Josh Boyer]

On Mon, 2006-11-06 at 15:09 +1100, Benjamin Herrenschmidt wrote:
> > > 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.

Hm.. that might be ok.  I'm hoping to get back to working on something
soon so I'll be able to tell more later.  Maybe Matt knows for sure.

It'll probably break out-of-tree drivers though once the merge happens
for 4xx.  Could we leave ioremap64 around for a bit with a deprecation
warning?

josh