On Mon, 30 Jul 2012, 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. Not necessarily. Consider all the devices that to go through a mode switch before they can be used. Does the usb-modeswitch program turn on the avoid_reset_quirk attribute? Probably not. I'm not even sure that RESET_MORPHS is the right thing to look at here. It's possible for a device to retain important settings across a reset but lose them when power is removed. > - I'm not sure if it's true that all devices that need firmware will > have USB_QUIRK_RESET_MORPHS set. Alan, Oliver? Probably not, and in any case the situation is more complex than it first appears. (In fact, I wonder whether we really need that quirk flag at all -- as far as I can tell it's not doing anybody any good.) > - 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. > > 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 That doesn't sound right. Don't you mean: If the port is internal and not pluggable and there is no device attached, power off the port? If the port is unpluggable and has no device, I don't see what difference it makes whether the port is internal or external. > 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 > > - 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. Like other people, I'm dubious about these conditions. > 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. Really, what's the difference? Are you assuming that internal ports are always "unpluggable" (i.e., devices cannot be plugged into or unplugged from the port)? I'm not sure even that much is true. For example, my Asus laptop has a USB card reader that's built-in. The connection is definitely internal; the user cannot get at it (although I don't know what the ACPI tables have to say about it). But the card reader disconnects itself from the USB bus whenever there's no card inserted. At any rate, it seems that you should be focusing on pluggable vs. unpluggable rather than internal vs. external. > 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. > > 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 tend to agree that having the kernel make these decisions is fraught with difficulties, except in the most simple cases (unpluggable and no device present). Exposing the extra attributes to userspace can't hurt -- unless we want to change or remove them in the future! Alan Stern -- 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
