Re: [PATCH v2 06/14] USB: centralize usb port power policy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 26, 2013 at 11:40 AM, Oliver Neukum <oneukum@xxxxxxx> wrote:
> 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.
>

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux