On Mon, 2013-11-25 at 11:05 -0800, Dan Williams wrote: > 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. Can you please elaborate? It seems to me that hub_activate() deals with a survival of the power session just fine. There seems to be a fundamental misunderstanding here. 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
