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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
