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.
Regards
Oliver
--
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
