Re: [PATCH v7 0/6] ZPODD patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux