On Wed, Nov 13, 2013 at 11:11:12AM -0500, Alan Stern wrote:
On Tue, 12 Nov 2013, Sarah Sharp wrote:
No, but that last one can be subdivided into:
- implement hotplug vs hardwired policy
I think the original agreement when the USB 2.0 port power off work
went in was that hotplug vs
On Tue, 12 Nov 2013, Sarah Sharp wrote:
No, but that last one can be subdivided into:
- implement hotplug vs hardwired policy
I think the original agreement when the USB 2.0 port power off work
went in was that hotplug vs hardwired shouldn't make a difference in the
kernel. It would be
I have a USB 3.0 hub (not with me right now), which has either three or
four USB 3.0 ports exposed, and seven USB 2.0 ports. The OS sees it as
one USB 3.0 hub and two USB 2.0 hubs chained together. My guess is that
the manufacturer wanted to say they had a seven port USB 3.0 hub, but
On Wed, 13 Nov 2013, David Laight wrote:
I have a USB 3.0 hub (not with me right now), which has either three or
four USB 3.0 ports exposed, and seven USB 2.0 ports. The OS sees it as
one USB 3.0 hub and two USB 2.0 hubs chained together. My guess is that
the manufacturer wanted to
On Tue, 29 Oct 2013, Dan Williams wrote:
With the device model change and no longer telling the hub interface
device to pm_suspend_ignore_children() the pm subsystem will manage
this wake up for us.
Provided you don't try to make any power changes while the port is
suspended.
For
On Mon, 28 Oct 2013, Dan Williams wrote:
In fact, the reason for calling usb_autopm_get_interface was to prevent
the hub from being suspended while we change the port's power state.
Something like this may still be needed.
With the device model change and no longer telling the hub
On Tue, Oct 29, 2013 at 8:05 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 28 Oct 2013, Dan Williams wrote:
In fact, the reason for calling usb_autopm_get_interface was to prevent
the hub from being suspended while we change the port's power state.
Something like this may still
On Sat, Oct 26, 2013 at 7:40 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 25 Oct 2013, Dan Williams wrote:
This patch set makes a large number of significant changes to important
and subtle aspects of the USB stack. It would be a lot easier to
discuss in pieces; I can't possibly
On Fri, 25 Oct 2013, Dan Williams wrote:
On Fri, Oct 25, 2013 at 2:11 PM, Alan Stern st...@rowland.harvard.edu wrote:
All right, I'm starting to get the overall picture.
Thanks for the patience I really appreciate it.
You're welcome.
This patch set makes a large number of significant
On Thu, 24 Oct 2013, Dan Williams wrote:
Details:
1/ Port power policy needs 'connector' awareness.
It is a recipe for unintended device disconnects to turn off a
port while leaving its peer active.
It is a recipe -- what is it? Do you mean that under the current
On Fri, Oct 25, 2013 at 8:23 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 24 Oct 2013, Dan Williams wrote:
Details:
1/ Port power policy needs 'connector' awareness.
It is a recipe for unintended device disconnects to turn off a
port while leaving its peer active.
All right, I'm starting to get the overall picture.
This patch set makes a large number of significant changes to important
and subtle aspects of the USB stack. It would be a lot easier to
discuss in pieces; I can't possibly review the whole series in a
reasonable time.
And I wish the basic
On Fri, Oct 25, 2013 at 2:11 PM, Alan Stern st...@rowland.harvard.edu wrote:
All right, I'm starting to get the overall picture.
Thanks for the patience I really appreciate it.
This patch set makes a large number of significant changes to important
and subtle aspects of the USB stack. It
Summary:
Address the following issues for port power control:
1/ Port power policy needs 'connector' awareness.
2/ Reliable port power control requires coordination with khubd.
3/ Userspace needs full control, but also help coordinating port
power policy.
Even with these changes port power
On Thu, 24 Oct 2013, Dan Williams wrote:
Summary:
Address the following issues for port power control:
1/ Port power policy needs 'connector' awareness.
2/ Reliable port power control requires coordination with khubd.
3/ Userspace needs full control, but also help coordinating port
power
Hi Alan, thanks for taking a look.
On Thu, Oct 24, 2013 at 10:25 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 24 Oct 2013, Dan Williams wrote:
Summary:
Address the following issues for port power control:
1/ Port power policy needs 'connector' awareness.
2/ Reliable port power
16 matches
Mail list logo
