On Sat, 22 Sep 2012, Rafael J. Wysocki wrote: > > > I see. So the sr's runtime suspend may be useful even without the power-off > > > feature, right? > > > > Exactly. Even though the drive itself may not be powered off, by > > putting it into runtime suspend we gain the ability to suspend the > > ancestor devices. > > OK, so what about using a PM QoS-based approach as described (in general > terms) in this message in the "USB ports power off" thread: > > http://marc.info/?l=linux-pm&m=134831537224566&w=4 I'm not entirely sure. It may well work out better in this case than in the USB ports case. For the ZPODD stuff, the userspace control amounts to a single flag ("do not allow zero-power") which can easily be represented as a QoS constraint. For the USB ports, the situation is more complicated. The decision about whether or not to power-off a port depends not just on the port itself but also on the device plugged into the port, and there's no direct relation between the two in the sysfs device tree. (That could be fixed perhaps by adding symbolic links between them.) This should be discussed in the USB thread, though... Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
