Alan Stern writes: > I think this is subject to the same weakness Dmitry mentions: By the > time the driver would block on the new rwsem, it has already started > mucking with the device. Worse yet, it may hold a mutex that the > suspend method needs, thereby deadlocking the suspend. (That's what > would happen with serio->drv_mutex in the input layer.) > > Maybe the best answer is simply to fail all attempts at device > registration while a suspend is underway. At least that is a known > error path which drivers are prepared (in theory) to deal with. It > could be implemented quite easily with an rwsem, by making the > registration code use down_read_trylock. What about making a list of devices that drivers have attempted to register? While the system is suspending, if a driver attempts to register a device, put it on a list and return success. Then, after resuming, run through the list and actually process them. I guess removal during suspend/resume should remove the list entry, if the device is one of the ones on the list. Otherwise, is there a problem with letting removals proceed during suspend/resume? (In general removal can be notified after the device has physically disappeared IIRC, so driver unbind functions have to avoid touching the device or at least be prepared to deal with it not responding.) Paul. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
