On Tuesday 10 May 2005 1:20 pm, Alan Stern wrote: > On Mon, 9 May 2005, David Brownell wrote: > > ... > > Okay. > > > I've tested this only lightly since merging things from your patch, > > and there are various "should not matter" things I removed from the > > version I'd been working on, but this version is similar to your patch, > > or what's there now, [so] that I don't think it'll make trouble. > > I haven't tried it out yet, but it looks good. One thing stuck out > though: Why did you remove the test that prevents new drivers from trying > to bind to suspended devices?
It was superfluous; they'd get errors later, probe would still fail cleanly. And it seemed as if any fixes to that should sit a few layers up. > Also, I think that deadlock on dpm_sem in the PM core is now gone, so > there shouldn't be any problem about unbinding drivers with no suspend > method. I thought so too, but then I looked at the code and I see that device_release_driver() calls device_detach_shutdown() which normally calls dpm_runtime_suspend() which grabs dpm_sem; which is the deadlock, given it's called from a context which already holds that lock. (And it all seems rather counterproductive, since we want to unbind the driver specifically because there is no suspend method!!) There might be a way out though: adding a NOP shutdown method to the driver that usb_register() creates. (And maybe adding such an entry to struct usb_driver ... so the usbcore NOP method only gets used for drivers that don't provide their own.) > However there are a few things in there I want to touch up first > (including adding suspend/resume to usb-storage) -- and this will interact > with the new driver-model klist changes. So for now it's best to leave > that code as it is. I understand wanting to make storage handle suspend/resume; and it should be pretty straightforward, too. On the other hand, having a way around that dpm_sem deadlock would make all drivers handle suspend "sanely" without needing such new code ... and it'd be a huge step towards letting us get rid of CONFIG_USB_SUSPEND as an option (having its updated guts be the default). > Are you planning on making similar changes to the resume side? Done long ago. Testing is a different issue... takes much time! - Dave ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
