| Message ID | 1346309040-27112-2-git-send-email-aaron.lu@intel.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Thu, 30 Aug 2012, Aaron Lu wrote: > Add a new flag may_power_off for scsi device, it gives the user a chance > to control when the device is runtime suspended, can we remove its power > if possible. > > I'm planning using this flag for sr and sd. > > For sr, if user set 0 to may_power_off, we will disable runtime suspend > for ODD, since runtime suspend for ODD is wholly for zero power ODD, if > we can't power off the ODD, there is no meaning to do runtime PM on it. This doesn't seem like a good idea. Even though you may not be able to reduce the drive's power usage, you can still allow the runtime_suspend routine to succeed. This will tell the kernel to consider the drive as being in a suspended (and therefore unusable) state, allowing the kernel to do a runtime suspend of the SCSI host that the drive is attached to. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 30, 2012 at 10:24:39AM -0400, Alan Stern wrote: > On Thu, 30 Aug 2012, Aaron Lu wrote: > > > Add a new flag may_power_off for scsi device, it gives the user a chance > > to control when the device is runtime suspended, can we remove its power > > if possible. > > > > I'm planning using this flag for sr and sd. > > > > For sr, if user set 0 to may_power_off, we will disable runtime suspend > > for ODD, since runtime suspend for ODD is wholly for zero power ODD, if > > we can't power off the ODD, there is no meaning to do runtime PM on it. > > This doesn't seem like a good idea. Even though you may not be able to > reduce the drive's power usage, you can still allow the runtime_suspend > routine to succeed. This will tell the kernel to consider the drive as > being in a suspended (and therefore unusable) state, allowing the > kernel to do a runtime suspend of the SCSI host that the drive is > attached to. Thanks Alan, I agree that this doesn't quite follow the meaning of may_power_off. I tried to seperate runtime pm with runtime power off in v5 patch of ZPODD, please take a look to see if I did it the right way. Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h index 4bc4ac4..0bfc17f 100644 --- a/include/scsi/scsi_device.h +++ b/include/scsi/scsi_device.h @@ -157,6 +157,7 @@ struct scsi_device { unsigned can_power_off:1; /* Device supports runtime power off */ unsigned wakeup_by_user:1; /* User wakes up the ODD */ unsigned wce_default_on:1; /* Cache is ON by default */ + unsigned may_power_off:1; /* power off is allowed by user */ DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events */ struct list_head event_list; /* asserted events */
Add a new flag may_power_off for scsi device, it gives the user a chance to control when the device is runtime suspended, can we remove its power if possible. I'm planning using this flag for sr and sd. For sr, if user set 0 to may_power_off, we will disable runtime suspend for ODD, since runtime suspend for ODD is wholly for zero power ODD, if we can't power off the ODD, there is no meaning to do runtime PM on it. For sd, if user set 0 to may_power_off, we will not power off the device when it is runtime suspended. Signed-off-by: Aaron Lu <aaron.lu@intel.com> --- include/scsi/scsi_device.h | 1 + 1 file changed, 1 insertion(+)