On Tue, Nov 26, 2013 at 11:40 AM, Oliver Neukum <oneu...@suse.de> wrote: > On Mon, 2013-11-25 at 11:05 -0800, Dan Williams wrote: >> On Mon, Nov 25, 2013 at 3:33 AM, Oliver Neukum <oneu...@suse.de> wrote: >> > On Fri, 2013-11-22 at 12:18 -0800, Dan Williams wrote: >> >> On Fri, Nov 22, 2013 at 2:39 AM, Oliver Neukum <oneu...@suse.de> 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. >
Your concern was what to do when a device does not support reset_resume and I was merely pointing out that such a device will experience reset_resume as a part of hub_resume(). So, aside from possibly changing the occurrence frequency these port power changes are not introducing a new recovery scheme. What's unclear? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
