On Mon, Jul 30, 2012 at 10:27:08PM +0200, Oliver Neukum wrote: > On Monday 30 July 2012 13:00:18 Sarah Sharp wrote: > > > So far, the discussion on the mailing list seems to boil down to: > > > > Issues > > ------ > > > > - We need to issue a reset resume for all suspended devices that have > > been powered off. > > > > - We can't power off ports with connected devices that require firmware > > (e.g. bluetooth and 3G modems). The firmware would be lost when > > they're reset. > > > > - Some devices may morph into a different USB device on reset, so we > > need to avoid powering the port down when those devices are attached. > > Drivers for those devices will have the USB_QUIRK_RESET_MORPHS set. > > > > - I'm not sure if it's true that all devices that need firmware will > > have USB_QUIRK_RESET_MORPHS set. Alan, Oliver? > > Usually this is user space's responsibility. Given that we have a few firmware > uploaders in kernel space, we also need a port attribute for that. Ok, good to know. > > - Many drivers may turn on remote wakeup when a device is suspended, > > but userspace may not need the wakeup. An example would be if the > > user clicked "Disable bluetooth" from ConnMan. It obviously wouldn't > > care about remote wakeups from the bluetooth device. > > Then the driver should not request remote wakeup to be enabled. > If it does, it needs to be fixed. Ok, so if userspace closes the bluetooth interface, the driver shouldn't request remote wakeup, right? I'll have to look if this is true for bluetooth and modem devices. > > > Possible solutions > > ------------------ > > > > - We need a new interface driver flag to indicate a driver is fine with > > the port being powered off. Something like "supports_power_off". > > > > - 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 > > > > 2. If the device is internal and suspended, power off the port if all > > the following are true: > > It should also apply to ports of hubs in compound devices. The port power off behavior is different for those hubs, so I want to address that later. For USB 2.0 hubs, doesn't it detect connect events if you power off a port? Also, few USB 2.0 hubs actually power gate the ports (or all ports are ganged together), so I don't think this would actually save power. > > 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 > > > > - 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. > > > > > > 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 > > The policy is likely to be very similar. The question is about defaults rather > than mechanisms. > > > 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. > > > > 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? > > This needs to be configurable. > > It is not obvious that external ports should be handled like internal ports. > It might be sensible to apply auto-powerdown to a connected and opened > device, but to leave external ports on, so that hotplugs are detected. Sure. That's why I was proposing that external ports have the port power sysfs file set to "on" by default. Then userspace can set it to "auto" when it feels that external ports are ok to be powered off, because the user isn't interacting with the system, and it's ok to delay hotplug events. 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
