Messages in this thread | | | Date | Thu, 4 Sep 2003 21:03:41 +1000 (EST) | From | Paul Mackerras <> | Subject | Re: [PATCH] fix ppc ioremap prototype |
| |
Christoph Hellwig writes:
> ioremap_resource() looks like a fine idea. It's cleaner, easily > emulateable on <= 2.4 and solves the problem this hack wanted to > work around properly.
I agree.
> This still doesn't make the phys_addr_t a good interims solution, > though. Just use ioremap_resource from the beginning for those > drivers that care for the bigger address space on ppc44x. > > Paul, what does actually use this higher addresses?
We have drivers for on-chip peripherals that work from a struct ocp_device and call ioremap on the ocp_dev->paddr value, which is a phys_addr_t (although some of them use __ioremap instead). These drivers are used on 405-based systems (with 32-bit phys_addr_t) as well as on 440-based systems.
These drivers are in the linuxppc-2.{4,5} trees but most of them haven't made it into the official trees yet. They could all be audited and converted to use __ioremap, although it seems a bit arbitrary to say that you can't use ioremap in a an ocp driver if you're going to use it on a 440. I wouldn't expect it to be immediately obvious to a driver author just why you have to use __ioremap rather than ioremap in an ocp driver. The ioremap_resource idea would solve that problem of course, we would put a resource in the struct ocp_device instead of the physical address.
Paul.
- 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/
| |