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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
