On Wed, 22 Jan 2014, Dan Williams wrote:
> > That's not what I meant.
> >
> > Sending a request to khubd means doing something like this:
> >
> > set_bit(port1, hub->resume_child_bits);
> > kick_khubd(hub);
> >
> > khubd may start running even before kick_khubd returns. If it does
On Wed, Jan 22, 2014 at 6:48 AM, Alan Stern wrote:
> On Tue, 21 Jan 2014, Dan Williams wrote:
>
>> >> I think we agree that khubd needs to not look at the portstatus while
>> >> the port is down. pm runtime synchronization takes care of that and
>> >> prevents khubd from starting while the port i
On Tue, 21 Jan 2014, Dan Williams wrote:
> >> I think we agree that khubd needs to not look at the portstatus while
> >> the port is down. pm runtime synchronization takes care of that and
> >> prevents khubd from starting while the port is inactive. With that in
> >> place we can now make reque
On Tue, Jan 21, 2014 at 2:05 PM, Alan Stern wrote:
> On Tue, 21 Jan 2014, Dan Williams wrote:
>
>> > > We want to:
>> > >
>> > > 1/ prevent khubd from running while reset is in progress
>> >
>> > This is the open question mentioned above, if you add in the
>> > requirement that we also want to pre
On Tue, 21 Jan 2014, Dan Williams wrote:
> > > We want to:
> > >
> > > 1/ prevent khubd from running while reset is in progress
> >
> > This is the open question mentioned above, if you add in the
> > requirement that we also want to prevent a reset from starting while
> > khubd is running (exce
> The lock hangs off the usb_device rather than the the usb_port since it
> is meant to prevent unintended disconnects. Any portstatus vs khubd
> collisions are handled by pm runtime synchronization since there is no
> expectation that khubd resumes a usb_port.
>
> Once khubd has made a determinat
On Sat, 2014-01-18 at 08:59 -0500, Alan Stern wrote:
> On Fri, 17 Jan 2014, Dan Williams wrote:
>
> > > The basic idea of using runtime PM synchronization to prevent khubd and
> > > port power operations from interfering sounds good, and it is simpler
> > > than adding a new mutex. And I think we
On Fri, 17 Jan 2014, Dan Williams wrote:
> > The basic idea of using runtime PM synchronization to prevent khubd and
> > port power operations from interfering sounds good, and it is simpler
> > than adding a new mutex. And I think we can also use it to prevent
> > port power operations and port
On Fri, 2014-01-17 at 10:53 -0500, Alan Stern wrote:
> On Thu, 16 Jan 2014, Dan Williams wrote:
>
> > Maybe I need to consider it a bit longer, but introducing a per-port
> > mutex adds at least 2 new lock ordering constraints. A replacement of
> > hub->busy_bits with port_dev->lock now introduc
On Thu, 16 Jan 2014, Dan Williams wrote:
> Maybe I need to consider it a bit longer, but introducing a per-port
> mutex adds at least 2 new lock ordering constraints. A replacement of
> hub->busy_bits with port_dev->lock now introduces a constraint with not
> only the child lock, but also synchro
On Thu, 2014-01-16 at 16:18 -0500, Alan Stern wrote:
> On Thu, 16 Jan 2014, Sarah Sharp wrote:
>
> > > > What do you think about the rest of the patchset?
> > >
> > > I regret that I haven't taken the time to look through it yet. :-(
> > > I'll do my best to go through it soon.
> >
> > No wo
On Thu, 16 Jan 2014, Sarah Sharp wrote:
> > > What do you think about the rest of the patchset?
> >
> > I regret that I haven't taken the time to look through it yet. :-(
> > I'll do my best to go through it soon.
>
> No worries! I'm most interested in your comments about the changes to
> kh
On Wed, Jan 15, 2014 at 10:39:56AM -0500, Alan Stern wrote:
> On Tue, 14 Jan 2014, Sarah Sharp wrote:
>
> > > It's always possible for xhci-hcd to prevent the USB-2 root hub from
> > > being suspended by calling pm_runtime_get_noresume. The corresponding
> > > _put can be done after the USB-3 r
On Tue, Jan 14, 2014 at 1:47 PM, Dan Williams wrote:
> On Tue, Jan 14, 2014 at 1:42 PM, Sarah Sharp
> wrote:
>> On Mon, Jan 13, 2014 at 08:57:38PM -0500, Alan Stern wrote:
>>> On Mon, 13 Jan 2014, Sarah Sharp wrote:
>>>
>>> > On Mon, Jan 13, 2014 at 02:56:57PM -0800, Sarah Sharp wrote:
>>>
>>> >
On Tue, 14 Jan 2014, Sarah Sharp wrote:
> > It's always possible for xhci-hcd to prevent the USB-2 root hub from
> > being suspended by calling pm_runtime_get_noresume. The corresponding
> > _put can be done after the USB-3 root hub has been registered.
>
> Sure, it's on my todo list to fix th
On Tue, Jan 14, 2014 at 1:42 PM, Sarah Sharp
wrote:
> On Mon, Jan 13, 2014 at 08:57:38PM -0500, Alan Stern wrote:
>> On Mon, 13 Jan 2014, Sarah Sharp wrote:
>>
>> > On Mon, Jan 13, 2014 at 02:56:57PM -0800, Sarah Sharp wrote:
>>
>> > > I haven't looked at this too closely, but what happens if:
>>
On Mon, Jan 13, 2014 at 08:57:38PM -0500, Alan Stern wrote:
> On Mon, 13 Jan 2014, Sarah Sharp wrote:
>
> > On Mon, Jan 13, 2014 at 02:56:57PM -0800, Sarah Sharp wrote:
>
> > > I haven't looked at this too closely, but what happens if:
> > > - the USB 2.0 roothub is registered
> > > - userspace
On Mon, 13 Jan 2014, Sarah Sharp wrote:
> On Mon, Jan 13, 2014 at 02:56:57PM -0800, Sarah Sharp wrote:
> > I haven't looked at this too closely, but what happens if:
> > - the USB 2.0 roothub is registered
> > - userspace immediately sets autosuspend_delay to zero and
> >pm_qos_no_port_powe
On Mon, Jan 13, 2014 at 2:56 PM, Sarah Sharp
wrote:
> On Tue, Jan 07, 2014 at 12:29:44PM -0800, Dan Williams wrote:
>> ACPI identifies peer ports by setting their 'group_token' and
>> 'group_position'
>> _PLD data to the same value. If a platform has tier mismatch (see Appendix D
>> figure 131 i
On Mon, Jan 13, 2014 at 02:56:57PM -0800, Sarah Sharp wrote:
> On Tue, Jan 07, 2014 at 12:29:44PM -0800, Dan Williams wrote:
> > ACPI identifies peer ports by setting their 'group_token' and
> > 'group_position'
> > _PLD data to the same value. If a platform has tier mismatch (see Appendix
> > D
On Tue, Jan 07, 2014 at 12:29:44PM -0800, Dan Williams wrote:
> ACPI identifies peer ports by setting their 'group_token' and 'group_position'
> _PLD data to the same value. If a platform has tier mismatch (see Appendix D
> figure 131 in the xhci spec), ACPI can override the default peer port
> as
21 matches
Mail list logo
