On Mon, 9 May 2005, David Brownell wrote: > Since the only remaining point of that second usb_suspend_device() > parameter was to support the recursion, I removed it. By analogy > to pci_set_power_state(), it doesn't need the parameter ... USB > hardware only has one "suspend" state, and resume() is separate.
Sounds fine. > Also the software-only state (interface->dev.power.power_state) > stays as SUSPENDED whenever the driver is unbound, simplifying > the logic to test when a device can be suspended and getting > ready to kick in device-level autosuspend. 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, 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? 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. 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. Are you planning on making similar changes to the resume side? Alan Stern ------------------------------------------------------- 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
