On Mon, Nov 25, 2013 at 3:33 AM, Oliver Neukum <oneukum@xxxxxxx> wrote: > On Fri, 2013-11-22 at 12:18 -0800, Dan Williams wrote: >> On Fri, Nov 22, 2013 at 2:39 AM, Oliver Neukum <oneukum@xxxxxxx> wrote: >> > On Fri, 2013-11-22 at 01:07 -0800, Dan Williams wrote: >> >> Move all port power policy evaluation to usb_port_runtime_suspend(). >> >> Makes it clearer what blocks port power off and is preparation for >> >> follow on changes that >> >> 1/ make a usb_port a proper (device model) parent >> >> of a usb_device >> >> 2/ advertise to userspace what constraints are keeping a >> >> port powered >> >> 3/ changing the meaning of the usb_port runtime suspended >> >> state. >> >> 4/ add new constraints peer-port-power-state and connect_type >> > >> > It seems to me that if you use reset_resume() you must >> > check whether all children further down in the tree support >> > reset_resume() in their drivers. >> > >> >> If a device does not support reset_resume I expect it will fail >> autosuspend_check(). When that happens the device will stay in the > > Why? They would fail only if, needs_remote_wakeup were set. > It may or may not be. It also fails in the simple case where the driver has disabled autosuspend for the device. If a device is enabling autosuspend and does not support reset_resume it will already have issues with its parent hub going into autosuspend. The hub resume path forces reset_resume for child devices. For this port power off implementation, as long as the device disables autosuspend the entire path to the device will remain active. However, this does raise the question of whether devices that have the USB_QUIRK_RESET flag set should have autosuspend disabled. It seems only userspace sets that flag, so maybe userspace is also taking responsibility for blocking autosuspend. >> RPM_ACTIVE state. Consequently its parents and ancestors will be >> prevented from transitioning to RPM_SUSPENDED. I think this would > > Why a device can have power and still be suspended. Which level are we talking about here, the port or the child device? The status quo is that the power supply for the port stays active while the device itself is suspended. Powering down the port on child suspend is optional and incremental. >> have been a problem prior to "[PATCH v2 07/14] USB: make usb_ports >> proper parents of their child usb_devices" which makes hubs honor the >> runtime pm state of their descendants. > > Still I cannot see how the generic code can help. The generic code > knows suspend or active. It knows nothing about power. We enforce 'active' == 'powered on' and the generic code enforces hubs and ports 'active' while child devices are 'active'. For a device that does not support reset_resume its driver had better disable autosuspend, or otherwise be safe to rebind the device on resume. >> Might be something powertop should look at, if it does not already, >> i.e. suggest moving a usb device when it is holding up a tree of >> devices that could otherwise sleep. > > How would it do that if you don't export a value for that? I'm thinking power/runtime_status == "unsupported" -- 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
