patchset "b18" updated

[Dominik Brodowski]

An updated version of the "b18" pcmcia patchset is available at
http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration.tar.bz2

Changes to the previous version include:
- reference counting in bind_request fixup
- unconditionally send out REMOVAL events on closing of cardmgr access
- use driver_find instead of legacy implementation
- rediff


A "bigdiff" is available in two parts at
http://www.brodo.de/patches/2004-11-13/pcmcia-b18-part1
and
http://www.brodo.de/patches/2004-11-13/pcmcia-b18-part2

and individual patches as follows:



http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/01-move-and-remove-stuff

Move pcmcia_{de,}register_client() from cs.c to ds.c,
and remove the unused pcmcia_get_{first,next}_client() calls -- they would
be an unnecessary hassle to deal with in the next patches.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/02-license

As discussed previously, my integration of ds.c and cs.c 
with the driver model can and will only be available under 
the GPL, as it's too much derived of other buses' implementation 
of integration with the driver model.

cs_internal.h did only contain the MPL header before - I contacted
Dave Hinds because of this, and as far as he can tell, it was just an
oversight that this was not marked as dual-licensed as the other files 
are.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/03-ds-kref

Switch pcmcia_bus_socket's reference counting to struct kref. Also,
split the access by number into two calls, so that get_bus_socket can be
used in a more generic way.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/04-cs-class_dev

Add pcmcia_{put,get}_socket


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/05-ds-grab-cs-ref

Grab a reference of struct pcmcia_socket for every struct pcmcia_bus_socket.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/06-ds-get-ref-for-p_dev

Obtain a reference to struct pcmcia_bus_socket for each pcmcia_device. This
means that pcmcia_device always holds an indirect reference to struct 
pcmcia_socket as well.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/07-p_dev-client-pointer

Add a pointer to the "client" structure to struct pcmcia_device.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/08-send_event-p_dev

Use a struct pcmcia_device-based approach to inform "clients" of 
events. It needs to be done using bus_for_each_device() so that
we don't need to take the device_list spinlock.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/09-removal-p_dev

Use pcmcia_dev instead of the "client" single-linked list to mark
clients as stale.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/10-move-inside-ds

Move some code around in ds.c. Avoids forward-declarations, and keeps
related code close to each other.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/11-register_client-p_dev

Search the devices_list for an UNBOUND client in register_client,
instead of the single linked list clients.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/12-direct_ordered_unbind

Restructure unbind_request():
Before, unbind_request was called by cardmgr on the following occasions:
a) if the CS_EVENT_CARD_INSERTION event failed
b) during do_remove(), which is called on
	1) when cardmgr is informed of a CS_EVENT_CARD_REMOVAL event
	2) when cardmgr is informed of a CS_EVENT_EJECTION_REQUEST event, if
	   do_check() succeeds
	3) cardmgr exit (SIGINT/SIGTERM), if do_check() succeeds

We can ignore a), as the user is informed of the problem anyway, and can
take appropriate action then (eject the card, update config, write new driver,
insert card...).

b1) can be done directly, even before the userspace cardmgr is informed. This
speeds up the call to ->detach().

b2) All drivers I checked were based on the assumption that a 
CS_EVENT_CARD_REMOVAL event is received _first_, before a call to
->detach(). Most notably, some drivers issue first a call to 
their release() function [which else is called during EVENT_CARD_REMOVAL] 
during ->detach() if it hasn't been issued before. So, it doesn't hurt
if unbind is only called during the EVENT_CARD_REMOVAL step, and not
during EJECTION_REQUEST. The REMOVAL step is only called anyway if 
EJECTION_REQUEST succeeds, and the latter can only succeed if do_check() 
succeeds.

b3) If cardmgr exits, ds_release() is called. We can check for any
16-bit devices there, and call a CARD_REMOVAL event there. Only difference
is that a failure of do_check() does not block CARD_REMOVAL. IMHO this
is accepatble.


Consequences:
- call unbind_request during CARD_REMOVAL handling, even before userspace
  is informed.
- return "0" if UNBIND_REQUEST is called from userspace.
- clean up 16-bit pcmcia devices existing during cardmgr exit
- the driver's event handler is called with CARD_REMOVAL _always_ before
  ->detach() is called.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/13-bug_on_dev_list_not_null

All in-kernel PCMCIA devices do unregister their client in their respective
->detach() function after a REMOVAL event. So, AFAICS, the dev_list iteration
should always be false.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/14-bug_on_list

BUG if the socket's list of clients is not empty on shutdown and/or
removal


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/15-move_client

Move the struct client_t inside struct pcmcia_device. This means it gets
proper reference counting as well. The clients list inside struct pcmcia_socket
can be removed now.


http://www.brodo.de/patches/2004-11-13/pcmcia-b18-client_t_integration/16-driver_find

Use driver_find() in ds.c instead of legacy implementation, and make use of
its reference counting awareness.