[PATCHES 2.5] pcmcia: add struct pcmcia_device

[Dominik Brodowski]

On Sat, Apr 19, 2003 at 05:07:37PM +0100, Russell King wrote:
> 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.

Great. 

> 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.

Sounds good - and doesn't seem to break anything outside drviers/pcmcia/* . 
At least nothing that isn't broken for statically mapped sockets anyway...

>  As for the resource ioctl, I'm hoping this will die.

That's the point. The question is, how? 

a) for statically mapped sockets
Is _any_ user input needed (buggy firm- or hardware don't count) to know what
resources (irq, io, mem) are used by this socket? If not, there's no need 
for the ioctl, right?

b) for dynamically mapped sockets - How about this: 
  I.)   All resources marked by kernel/resource.c as used are "off-limits" for
        PCMCIA.

  III.) A new sysfs interface allows users to specify other "off-limits"
        areas for PCMCIA -- a simple parser might even be able to transform
        the existing /etc/pcmcia/config.opts to a script which calls this
        sysfs interface.
        One question is left, though: should these resources be marked
        "reserved" in the whole resource tree, or only "off-limits" for
        PCMCIA? If we decide to do the former, the code should be inserted
        into kernel/resource.c (and a 1:1 config.opts->new_scheme
        transformation might prove bad for other resource users.)

  IV.)  Only after this is done, the in-kernel PCMCIA code is started, e.g. 
        by a sysfs interface, it accepts insert calls etc. On legacy-free
        systems or whenever the socket is behind a PCI-PCI bridge(?),
        where all available resource are known and step II may be skipped,
        we might want to add a boot argument and/or compile option so that
        the kernel PCMCIA code may start durin the module_init or 
        late_initcall stage. Support for "coldplugging" in the hotplug
        scripts will be needed for statically mapped sockets anyway.

However, doing it this way also means that we break the existing cardmgr
ioctl approach for _all_ users. Keeping a backwards-compatible mode is
doable, but nasty; and for reasons pointed out in your previous mails
cardmgr still needs at least one further call which equals step IV in the
list above.

> 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.

Is the IRQ for statically mapped sockets fixed as well?

> 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.

Good. What are the rough edges? It seems to me that this is the showstopper
before struct pcmcia_device can be merged (and much other fancy stuff
depends on that...)

	Dominik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20030419/1adba5c9/attachment.bin