Messages in this thread | | | Date | Thu, 4 Sep 2003 10:22:35 +0200 | From | Christoph Hellwig <> | Subject | Re: [PATCH] fix ppc ioremap prototype |
| |
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..
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |