On Fri, Mar 29, 2013 at 02:37:24PM +0800, Lan Tianyu wrote: > On 2013/3/29 6:43, Sarah Sharp wrote: > >On Thu, Mar 28, 2013 at 05:00:23PM -0400, Alan Stern wrote: > >>On Thu, 28 Mar 2013, Sarah Sharp wrote: > >>>On Thu, Mar 28, 2013 at 01:11:02AM +0800, Lan Tianyu wrote: > >Now I'm a bit confused and I'll have to look at the code again. I can't > >remember if Tianyu made the kernel add a PM_QOS constraint to set the no > >power off flag for hot pluggable ports, or if we expect userspace to use > >the connect type sysfs file to figure out it shouldn't write auto to the > >file. > Actually, I exposed pm qos flags for usb port via dev_pm_qos_expose_flags(). > It creates power/pm_qos_no_power_off under usb port sysfs directory. > User can echo 0 > pm_qos_no_power_off to power off the empty port. Ugh. I agree with Alan that the name should be pm_qos_keep_power_on. However, what happens if you echo 0 to pm_qos_no_power_off, the power/control is set to auto, and there's a suspended USB device attached to the port with remote wakeup enabled? Will the port be powered off? I don't think it will with the current patchset, but I will have to double check. Maybe you have an Android smartphone or tablet, the user pushes the button to turn off the screen. In that case, you want to physically power off any USB devices, including ones that may be in USB device suspend with remote wakeup on, like a USB touchscreen. With the proposed patchset, you can do that through usbfs, but it feels awkward to have the PM QOS constraints and the manual power off in two separate places. I think if we're adding the usbfs interface, we should also add a manual 'off' to the port power/control file. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
