Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sat, 2009-10-31 at 10:31 +0100, Rafael J. Wysocki wrote:

> > To me the proper approach would be to split it so that
> 
> Well, agreed, but ...
> 
> >  - early_resume() restores power & config space etc... so that existing
> > devices can move on (might check for removal). There's no other hotplug
> > activity
> 
> ... that's exactly what doesn't work at the moment.

BTW. This is a PCMCIA problem, a Cardbus or both ? I'll see if I can dig
something on monday ?

From the little email history I caught, it smells like pcmcia old style.

I don't see a problem per-se with the mutex usage with the new interrupt
masking style as Linus says. socket_resume() also looks reasonably sane,
it's the whole handling of removal that should be deferred. Maybe
instead of doing socket_remove_drivers()...send_event() etc.. in there,
we could simply just shut the socket down (PCMCIA drivers should cope
with sockets returning ffff's for a short amount of time), flag it dead
in skt->state and have the "late" resume  actually fire off the driver
removal and sending of the event.

BTW. Have we ever documented whether it's kosher to ->remove() a driver
before ->resume()'ing it ? (In which case obviously we wouldn't resume
it).

Cheers,  
Ben.