On Fri, Mar 29, 2013 at 01:23:14PM -0400, Alan Stern wrote: > On Fri, 29 Mar 2013, Sarah Sharp wrote: > > > 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. > > It shouldn't be, because remote wakeup is enabled. But what about the > case where remote wakeup is disabled? Will writing a 0 to > pm_qos_no_power_off cause the power to be turned off? > > Or what about the case where there's no device attached to the port? I > guess both questions amount to the same thing: When the user writes to > a pm_qos_* file, does the code call pm_runtime_idle? Tianyu? > > 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. > > That's not so easy to do. power/control is owned by the PM core, not > by USB. From the PM core's perspective, "power off" is merely a > variant of "suspend". The USB subsystem gets to choose which variant > to use, based on various constraints that userspace has imposed. Hmm, that's unfortunate. > In fact, if the user wants to, it is possible to set the port's pm_qos > file to allow power off and then manage the port's actual behavior > entirely by means of its power/control file. I sort of think that > would be a cleaner approach ... but there may have been some reason for > using the separate pm_qos attribute; I can't remember. I think the implementation would be cleaner as well. I can't remember why we don't have power/control set to 'auto' and power/pm_qos_no_power_off set to '1' by default. I think the argument was about how to deal with multiple userspace programs that wanted to prevent port power off? It seems like you would want the opposite default (power/control set to 'on' and power/pm_qos_no_power_off set to '0'). That way, something like a firmware loader can express they don't want to power off a device by writing 1 to power/pm_qos_no_power_off, and programs like powertop can respect those decisions by just setting power/control to 'auto'. Right now, if powertop wanted to attempt to enable automatic port power off, it would have to overwrite any preferences the previous userspace programs expressed. > Also, bear in mind that the proposed patch does not give userspace a > way to power off ports via usbfs. What the new code does is a > power-off reset -- it turns off power to the port, waits a short time, > and then turns power back on. I think we need two separate IOCTLs: turn off the port power and turn it on. Then we get the manual port power off for our QA testing, distros can make interesting policies about manually powering off ports, and userspace can choose how long they want the port to be off. After all, different devices may need a longer powered-off period than others. 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
