On Mon, Jul 30, 2012 at 10:35:37PM +0200, Bjørn Mork wrote: > Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> writes: > > - In addition to the port power sysfs values of "on" or "off", we also > > need an "auto" value that attempts to apply a smart in-kernel policy > > to when to power off the port. That policy might look like: > > > > 1. If the device is internal and unpluggable, power off the port > > How do you detect the "unpluggable"? Did you consider rfkill switches > "plugging" and "unplugging" internal devices? ACPI provides methods to say whether a USB port is internal or external, and whether it's "connectable", meaning whether a USB device will ever connect to it. I would hope (although BIOS writers get the ACPI tables wrong all the time) that devices behind rfkill switches would be marked as connectable internal ports. > > 2. If the device is internal and suspended, power off the port if all > > the following are true: > > > > a) all interface drivers have supports_power_off set, or no > > interface drivers are bound and usbfs has not claimed the > > device. > > b) remote wakeup is disabled > > c) USB_QUIRK_RESET_MORPHS is not set > > Why can't that be a userspace decision? I.e. drop all this policy in > the kernel stuff, and just implement: > > > - If userspace wants a port to be powered off, and one of the interface > > drivers doesn't set supports_power_off or the driver enables remote > > wakeup, then userspace will need to unbind or unload the driver. Yes, we could do that. However, I would really like the port power off to actually be *used*, so I'm not happy with leaving it completely off by default. I'd like unconnectable internal ports to have the port power setting on "auto" by default, and have the default auto policy for empty ports to be powered off. If that's too controversial, I'll settle for getting the distros to write the udev rule to use the exported ACPI information to turn off unconnectable internal ports. Or write a powertop rule. > > So far, the discussion has been mainly focused on figuring out a smart > > policy for internal USB ports. However, I'd like to see the "auto" > > in-kernel policy extended to external USB ports. Perhaps we need to > > expose the ACPI internal/external port and connectable/unconnectable > > values through sysfs, and apply the policy to both internal and external > > devices? > > > > Then userspace could look at whether a port is internal or external, and > > decide when it makes sense to auto-power-off the port. It could decide > > to set an "auto" policy on all ports when the screen blanks. When the > > user starts interacting with the system and the screen turns back on, > > userspace could change the policy back to "on" for external ports and > > internal connectable ports. > > Yes, this is the way to go IMHO. > > BTW, what if the interaction started with a USB keyboard being plugged > in? No problem for you - that was the userspace daemon bad coice of > policy :-) I was envisioning some sort of check box in the screensaver settings like "turn off USB ports on screen blank". Then people who turn on their desktops by plugging in a USB keyboard can untick it and be happy. Those people with laptops who can turn the screensaver off by hitting a key on the built-in keyboard can check it and get better power savings. > > Then policy #1 would just change to "If the device is disconnected, > > power off the port" and policy #2 would apply to both internal and > > external suspended ports. > > > > Thoughts? > > I really think the kernel should limit itself to providing the basic > functionality (driver support flag and port power switch), and leave any > policy decisions for userspace to screw up. > > It's not like the kernel decides whether to enable autosuspend in the > first place... Actually, it does enable auto-suspend by default for USB hubs. 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
