On Thu, 23 Jun 2011, Rafael J. Wysocki wrote: > > Then maybe this disable_depth > 0 case should return something other > > than 0. Something new, like -EACCES. That way the caller would > > realize something strange was going on but wouldn't have to treat the > > situation as an error. > > I would be fine with that, but then we'd need to reserve that error code, > so that it's not returned by subsystem callbacks (or even we should convert > it to a different error code if it is returned by the subsystem callback in > rpm_resume()). > > > After all, the return value from pm_runtime_get_sync() is documented to > > be the error code for the underlying pm_runtime_resume(). It doesn't > > refer to the increment operation -- that always succeeds. > > That means we should change the caller, which is the SCSI subsystem in this > particular case, to check the error code. The problem with this approach > is that the same error code may be returned in a different situation, so > we should prevent that from happening in the first place. Still, suppose > that we do that and that the caller checks the error code. What is it > supposed to do in that situation? The only reasonable action for the > caller is to ignore the error code if it means disable_depth > 0 and go > on with whatever it has to do, but that's what it will do if the > pm_runtime_get_sync() returns 0 in that situation. > > So, in my opinion it simply may be best to update the documentation of > pm_runtime_get_sync() along with the code changes. :-) The only reason you're doing this is for the SCSI error-handler routine? I think it would be easier to change that routine instead of the PM core. It should be smart enough to know that a runtime PM call isn't needed during a system sleep transition, i.e., between the scsi_host's suspend and resume callbacks. Maybe check the new is_suspended flag. You'd also have to make sure the scsi_host wasn't runtime suspended when the sleep begins, rather like PCI. I'm still not clear on why the error handler needs to run at this time. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
