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. > - 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. > 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. > 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. Regards Oliver -- 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
