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. > 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. > 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. > 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? 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
