Re: [PATCH] fix ppc ioremap prototype

[Christoph Hellwig <hch@lst.de>]

On Thu, Sep 04, 2003 at 01:12:28AM -0700, Linus Torvalds wrote:
> 
> On Thu, 4 Sep 2003, David S. Miller wrote:
> > 
> > My suggestion is to just pass a resource and an offset to ioremap().
> 
> Actually, my suggestion right now is to ignore the issue, and let the 
> current ppc440x code stand as-is. After all, it works, and it does what 
> the ppc people want. We may at some point switch over _all_ ioremap users, 
> but there is no real reason to do so right now.

So how should it work?  What basically all drivers to curretnly is
to have a unsigned long they get from pci_resource_start and pass it
to ioremap(), e.g. in tg3.c:

	unsigned long tg3reg_base, tg3reg_len;

	...

	tg3reg_base = pci_resource_start(pdev, 0);

	...

	tp->regs = (unsigned long) ioremap(tg3reg_base, tg3reg_len);

with the ppc4xx code you'd have to change the unsigned long to
a phys_addr_t to actually work with the high io addresses, which doesn't
exist on the other architectures.

Given that patch must make any sense (which I don't know as no one
even tried to explain it!) the pci code on ppc4xx doesn't actually use
the high bits of phys_addr_t.  But then this whole change to ioremap
doesn't make any sense and those arch-specific drivers should just use
a ioremap64 variant which seems to be present on ppc44x aswell..