Hi! > At this point I'm starting to feel like the proverbial > "man-in-the-middle". Recently I submitted a patch adding Rock and a hard place? > suspend/resume > support to the usblp driver. Greg objected to it because it added > explicit checks for whether the driver was suspended before starting up > I/O operations. He said that such checks did not belong in USB drivers, > they belonged in the USB core. (You can read his original comments in > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=113418897301873&w=2 > > .) So now what should we do? > > Require userspace to rmmod usblp before suspending? No. > Add suspend and resume methods to usblp, but make it so they > only cancel outstanding I/O, while relying on usbcore to fail > any new I/O requests? It is not *that* bad, actually. In system suspend/resume cases, no new I/O requests can happen, because userspace is frozen. Because of runtime suspend, you should handle I/O errors properly, but you should handle I/O errors properly, anyway, so... looks like a solution to me. > Neither of those feels good to me. The only other options I can think of > are: > > Unbind usblp in lieu of suspending it. If this can be done in reasonable ammount of not-too-ugly code, why not? I think that even Patrick can be convinced by nice patch. > Make usblp check whether it is suspended before submitting any > I/O requests. Ugly. Pavel -- Thanks, Sharp!
