Re: [PATCH] fix ppc ioremap prototype

[Deepak Saxena]

On Sep 04 2003, at 22:59, Paul Mackerras was caught saying:
> Russell King writes:
> 
> > Using the high flag bits probably isn't a good idea for two reasons:
> > 
> > 1. We already use bit 31 to indicate the busy status:
> > 
> >    #define IORESOURCE_BUSY         0x80000000      /* Driver has marked this resource busy */
> > 
> >    However, it looks like bits 27 to 17 are currently unused.
> 
> Using some flag bits would work but it seems like a bit of a kludge.
> Maybe the struct resource needs to have a pointer to the struct device
> which owns it?  Or maybe just a `sysdata' field?
> 
> > 2. The resource tree won't know about the upper bits or whatever sitting
> >    in flags, and as such identical addresses on two different buses will
> >    clash.
> > 
> > Resource start,end needs to be some unique quantity no matter which (PCI)
> > bus you are on.
> 
> They are non-overlapping for PCI buses in the same domain.  Perhaps
> the sensible thing is to have a separate resource tree for each PCI
> domain (actually two trees, for I/O and memory space), and have them
> contain bus addresses rather than physical addresses.  I don't know if
> the generic iomem_resource and ioport_resource are still useful if we
> do that.

I think we need to a have a resource tree per _bus_, not just PCI.
I have systems which have overlapping devices in multiple PCI domains
and devices on the local memory bus that also overlap. Before someone
yells at me about ioremap() only being for PCI memory resources,
it's already used throughout the kernel for locally mapped devices.

Ideally, the resource "system" as it exists would be rewritten
with something that ties into the device tree a bit by having
each resource being owned by a device.  One then calls
ioremap_resource() which on platforms that need it can look
at the resource->dev ptr to determine how to map that resource.

~Deepak

-- 
Deepak Saxena
MontaVista Software - Powering the Embedded Revolution - www.mvista.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/