[PATCHES 2.5] pcmcia: add struct pcmcia_device

[Russell King]

On Sat, Apr 19, 2003 at 05:34:53PM +0200, Dominik Brodowski wrote:
> ... but if we decide to break userspace -- and this is what you suggest, in
> fact, a "compatibility mode" doesn't count :) -- we might want to break it 
> once and forever wrt adding/removing available resources. This includes but
> is not limited to not using ioctls but sysfs interfaces. But how should it
> work? Pavel's suggestion of last Wednesday comes to my mind... copying it to
> this place now:
> 
> On Wed, Apr 16, 2003 at 04:45:46PM -0400, Pavel Roskin wrote:
> > 1) Card driver determines that the card needs e.g. 2Mb of memory
> > (4k-aligned) and 0x40 bytes of I/O space starting at 0xXXXX0300.  The
> > card formulates requests where all those requirements are represented in
> > some way.
> > 
> > 2) pcmcia_core redirects the requests to the socket driver.
> > 
> > 3) Socket driver (and not pcmcia_core!) determines whether the hardware
> > can provide the windows of the required size and with required alignment.
> > SS_CAP_STATIC_MAP and io_offset should be obsoleted.
> > 
> > 4) Socket driver requests the necessary resources from the kernel resource
> > pool.  Successful request locks the resource immediately.
> > 
> > 5) Socket driver programs the hardware to decode addresses in the
> > allocated range.
> > 
> > 6) Card driver starts using the new memory and I/O windows.

Well, this is what is becoming mapstatic.c and mapwindow.c - for instance,
today I can build a PCMCIA subsystem without rsrc_mgr.c and mapwindow.c
for statically mapped sockets.

However, mapstatic.c and mapwindow.c are tied to the core by two things -
the way we decide which to use, and the resource ioctl call.  Eventually,
the socket drivers will pass a pointer to the map_ops structure to the
core, allowing mapstatic.c and mapwindow.c to become modules in their
own right.  As for the resource ioctl, I'm hoping this will die.

There is one additional snag for windowed sockets - rsrc_mgr.c also
contains a load of IRQ-"resource" based code which is pretty much tied
into the pcmcia core at the moment, but we ideally want rsrc_mgr.c to
be part of mapwindow.c.

We will go further and combine mapstatic.c with the statically mapped
socket drivers - the current structure is completely wrong for these
beasts.

Most of the ideas Pavel's coming up with are already known by myself and
I have plans and solutions in various stages of evolution to them.

-- 
Russell King (rmk at arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html