On Mon, Jul 30, 2012 at 09:28:36AM +0200, Oliver Neukum wrote:
> On Monday 30 July 2012 11:34:10 Lan Tianyu wrote:
> > The hub is always supposed to support reset and its persist is enabled.
>
> By default, not necessarily always. User space may disable it.
>
> > So hub doesn't need attribute avoid_reset_quirk. The patch is to take
> > attribute avoid_reset_quirk out of usb device's attribute group and
> > add or remove it in the usb_create/remove_sysfs_dev_files() if the device
> > is not a usb hub.
>
> Why? What is gained doing so? Without further explanation about the need
> or benefit of doing so, why do you want to make hubs different from
> other devices?
Along those lines, Tianyu, can you share what your master plan for
implementing the automatic powering off of ports? I think it would help
to understand the bigger picture when looking at small patches like
these.
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?
- 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
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.
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.
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?
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
