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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
