[PATCHES] move code for !STATIC_MAP to extra module
David Hinds
dhinds at sonic.net
Mon Nov 8 16:51:18 EST 2004
On Mon, Nov 08, 2004 at 08:00:47PM +0000, Russell King wrote:
> On Mon, Nov 08, 2004 at 09:14:29AM -0800, David Hinds wrote:
> > On Mon, Nov 08, 2004 at 07:57:14AM +0000, Russell King wrote:
> > > Also note that the resource problem you mention isn't the problem of
> > > the PCMCIA core anymore - it's now up to the individual card drivers
> > > themselves to claim resources using request_region and
> > > request_mem_region.
> >
> > I don't think it matters which party does the request_region() call;
> > the resource allocator in the PCMCIA core still needs to do conflict
> > avoidance for static mapped sockets.
>
> No it doesn't. There isn't a resource allocator for statically mapped
> sockets.
>
> The "two drivers accessing the same IO address" problem is solved purely
> by the drivers doing the request_region() call and checking the return
> value. PCMCIA is no different in this respect on static sockets from an
> ISA or PCI device plugged into a socket.
Perhaps we are talking about two different problems. The problem I am
talking about cannot be solved by the client drivers. Consider a dual
function card where each client driver requires its own IO window. Or
one driver that requires several windows with different attributes, or
several memory windows. The core PCMCIA code must be able to assign
non-overlapping resource ranges in response to these requests. That
requires some level of resource management at the socket level,
whether the socket is static mapped or not.
This is a real bug and it has been reported to me on the ARM platform
for multifunction IO cards with the 2.4 kernel PCMCIA drivers, though
I didn't recognize it as such at the time. The standalone drivers
don't have this problem for IO windows; both the standalone and kernel
drivers are broken for managing multiple memory windows.
-- Dave
More information about the linux-pcmcia
mailing list