New PCMCIA

[Pavel Roskin]

Hi, Dominik!

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

It's nice to hear that somebody is working.

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

Just looked at that.  Looks very promising.  I'm a bit reluctant to jump
to 2.5 kernel to test all that, but I guess it's about time.

> > 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 :-)

... and it was the first message to the list.

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

Sometimes I wish I could just fork() or clone() to work on this :-)

> 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 maintains
> 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 .... :))

OK, so I think Russell may be interested to look at the plx9052 driver:

http://www.red-bean.com/~proski/plx9052/

It works with wireless cards only, but it could work with more cards if
their drivers were more flexible with resources.  It's a perfect example
where static mapping for both memory and I/O is needed.  While it's
possible to remap both by accessing PCI registers, it's quite dangerous
and should be avoided IMHO.  I'd hate to move the PCI resources around to
placate the existing PCMCIA drivers.

We could also "cripple" yenta_socket and disable remapping of resources.
That would be useful for fixing client drivers.

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

Yes, the module registration/unregistration is the first step, and I see
that you are working on it already.

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

Race conditions are already pretty bad on uniprocessor ARM processors I'm
dealing with at work.  With certain configurations, reinserting a network
card gives you eth2, eth3, eth4 and so on.  This was traced to the timers.

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

That's fine with me.

> > 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 keep in mind that it's rarely needed, so there shouldn't be much
overhead if this feature is unused.

> It would be very helpful if you could test my current PCMCIA patches.

As soon as I switch to 2.5 kernel.

> 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 :)

Thank you for this information.  I think I'll start with making the
plx9052 driver work with pcnet_cs and ide-cs.  I also want to remove
timers from the drivers I can test.

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

I appreciate your encouragement,

-- 
Regards,
Pavel Roskin