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 from daemon mode, ds_release() is called.  I can't
    see a reason why this is good behaviour, especially as cards don't need
    cardmgr while running, only for setup.

Consequences:
- call unbind_request during CARD_REMOVAL handling, even before userspace
  is informed.
- return "0" if UNBIND_REQUEST is called from userspace.
- the driver's event handler is called with CARD_REMOVAL _always_ before
  ->detach() is called.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>