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 th
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
> > 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"
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 w
On Tue, Nov 12, 2013 at 3:10 PM, Sarah Sharp
wrote:
> On Mon, Oct 28, 2013 at 06:49:37PM -0700, Dan Williams wrote:
>> On Sat, Oct 26, 2013 at 7:40 AM, Alan Stern
>> wrote:
>> > On Fri, 25 Oct 2013, Dan Williams wrote:
>> >> > This patch set makes a large number of significant changes to importa
On Mon, Oct 28, 2013 at 06:49:37PM -0700, Dan Williams wrote:
> On Sat, Oct 26, 2013 at 7:40 AM, Alan Stern 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
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
> > suspe
On Tue, Oct 29, 2013 at 8:05 AM, Alan Stern 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 be needed.
>> >
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
On Sat, Oct 26, 2013 at 7:40 AM, Alan Stern 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 review the whol
On Fri, 25 Oct 2013, Dan Williams wrote:
> On Fri, Oct 25, 2013 at 2:11 PM, Alan Stern 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 changes to import
On Fri, Oct 25, 2013 at 2:11 PM, Alan Stern 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 would be a lot easier to
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 a
On Fri, Oct 25, 2013 at 8:23 AM, Alan Stern 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.
>> >
>>
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 th
Hi Alan, thanks for taking a look.
On Thu, Oct 24, 2013 at 10:25 AM, Alan Stern 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 control requires c
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
>
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 cont
18 matches
Mail list logo
