New PCMCIA

[Dominik Brodowski]

Hi Pavel,

(I know, the message was addressed to David, but well, ehm, I'm currently
working on updating PCMCIA behaviour in 2.5. as David is too busy[*], so....)

On Tue, Apr 08, 2003 at 07:07:42PM -0400, Pavel Roskin wrote:
> David Gibson (maintainer of orinoco_cs) told me that you are working on a
> new PCMCIA implementation for Linux.  I think it's a very important
> project.  I'd like to participate in the project.
That's wonderful! 

>  At least I want to know what is going on.
Have you seen the messages "[PATCHES 2.5] PCMCIA hotplugging, in-kernel-matching and depmod
support" and "[PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod
support" on the Linux kernel mailing list during the last week? That's
basically what I'm working on right now -- you can see the source at
http://www.brodo.de/pcmcia/index.html

> I tried to find the homepage of the project, but the closest thing I could
> find is the empty archives of linux-pcmcia at lists.infradead.org.  This
> message is also a test if this list is actually alive :-)
This list is hardly alive, mostly because of fear of actually having to take
over PCMCIA maintainership (and no, I don't want to do _that_...)

> In my opinion, the problems with the current implementation are following:
> 
> 1) Maintenance.  pcmcia-cs by David Hinds is supposed to be the old
> version, but it's maintained better than kernel PCMCIA.  It's very hard to
> get even a trivial PCMCIA patch into the kernel.  It seems that the kernel
> PCMCIA is maintained by the main developers (Linus Torvalds, Alan Cox) who
> are too busy with other things.  That's why some patches end up in
> pcmcia-cs only or in the kernel only.  Ideally, there should be a PCMCIA
> group working on the driver for both stable and development kernels, like
> it's done for other drivers (including MTD).

As David Hinds said development should only be done in the kernel version.
Because of that, drivers start to diverge more and more from the pcmcia-cs
package. Nonetheless bugfixes should be passed along. On who maintaines
PCMCIA in the kernel: Russell King <rmk at arm.linux.org.uk> is currently
working on updating cs.c and the resource management a bit (partly(?) to
properly support statically mapped sockets); Linus was very interested in my
PCMCIA patches (but asked Russell to serve as a "merge middle man"); Alan
merged them first without me even sending them to him :); others help out 
with the drivers. But basically the PCMCIA core doesn't have a maintainer
right now. Send your application in form of a few patches to .... :))

> 2) Insufficient code reuse.  Client drivers are supposed to do many things
> that are essentially the same for all drivers.  Fixes in some drivers are
> not propagated to others.  For example, detach() calls release() in
> pcnet_cs but not in xirc2ps_cs.  Both drivers are for very similar network
> cards.  orinoco_cs got rid of timers, but other drivers still have them.

That's right. The whole driver structure should be reworked either
incrementally that it may be done during the rest of 2.5. and 2.6., or (at
least) during 2.7. IMO the binding / client_registration should go away, and
instead struct pcmcia_device, struct pcmcia_socket and struct
pcmcia_bus_socket should be passed around.

> 3) Race conditions.  Many drivers use timers for no particular reasons.
> In some cases, the device fails to unregister because the user mode
> scripts finish at a "wrong" time.

Race conditions even will get worse as soon as the first HyperThreading CPUs
get into mobile systems. I haven't seen real locking in PCMCIA yet (and
haven't introduced it myself yet.... partly because some things I wanted to
do didn't work because of driver model locks....)
 
> 4) Resource allocation.  Some drivers allocate resources for the devices
> instead of taking resources from the socket driver.  This is bad because
> the resources ultimately belong to the socket, and it's the socket driver
> that knows which resources it can provide.  In particular, most socket
> driver remap memory and I/O windows to regions that a not reserved with
> the OS.  Checks to make sure that other devices are not affected are
> insufficient.  Socket drivers that don't provide remapping (e.g. my
> plx9052 driver) don't work with the client drivers that expect to use
> fixed addresses (e.g. pcnet_cs).

Yes.

> 5) No dynamic registration of sockets.  Socket drivers inserted after ds
> are not seen from cardmgr.  Ideally, pcmcia_core and ds should be merged,
> and the socket drivers should be loaded on top of them.

It works in 2.5.67. However, I'd advise against a merging of pcmcia_core and
ds. IMHO the pccard_core.ko should provide the basic (socket) services for
both cardbus and PCMCIA cards; cardbus.ko should add the basic functions
needed for CardBus support; and pcmcia.ko (formerly ds.c and a few other
stuff) should add the whole PCMCIA core support.

> 6) No driver-assisted identification of cards.  It should be possible for
> a client driver to check the card beyond its CIS data (e.g. check the
> firmware) and ask cardmgr to try another driver with the card.

Interesting idea. In my patches, driver indeed identify the cards -- but
solely based on a static table. Adding a ->probe() callback sounds like the
thing to do, yes....

> Please consider this message as public if you want to reply to it in
> another mailing list or forward it to other persons.
cc'ed to rmk.

It would be very helpful if you could test my current PCMCIA patches. 
Also, it would be really great if you could join the PCMCIA development
process, e.g. by starting to address some of the issues mentioned above,
fixing some of the bugs I introduced, etc. It might be a good idea to send
patches to rmk instead of Linus, so that PCMCIA patches don't clash; and
Russell has a very good history of getting good patches into Linus' tree :)

Also, I'd rather not spend too much time on 2.4. 2.6. seems to get out in
the near future; and I doubt many users will stay with 2.4. much longer
(2.6. is sooo much better than 2.4., and hopefully won't be that unstable
2.4. was and still is...) - Also limited resources (i.e. developer time)
should be spend where it helps most - and that's the development version for
sure.

Thanks,
	Dominik


[*] well, I'm very busy, too... that's why I don't want to become PCMCIA
maintainer....