[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871tb619vl.fsf@saruman.tx.rr.com>
Date: Tue, 1 Dec 2015 09:11:58 -0600
From: Felipe Balbi <balbi@...com>
To: Mathias Nyman <mathias.nyman@...ux.intel.com>, <daniel@...ra.org>
CC: <linux-usb@...r.kernel.org>, <stern@...land.harvard.edu>,
<linux-kernel@...r.kernel.org>
Subject: Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races.
Hi,
Mathias Nyman <mathias.nyman@...ux.intel.com> writes:
> On 01.12.2015 16:32, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Mathias Nyman <mathias.nyman@...ux.intel.com> writes:
>>> usb2 ports need to signal resume for 20ms before moving to U0 state.
>>
>> at least 20ms ;-) Recently, we decided to drive resume for 40ms to
>> support devices with broken FW.
>>
>
> True, but specs talk about 20ms, and I'm just trying to give some context for what's
> going on. This testpatch doesn't touch the timings.
>
> Daniel is able to trigger a USB2 xhci resume issue which I hope is fixed with this patch.
> This is especially made for his setup running a 4.3 kernel
>
> If this works I'll clean up all the "20ms" in the commit message and comments.
>
> Just noticed that xhci USB2 host initiated resume uses a hardcoded msleep(20).
> That needs to be changed to USB_RESUME_TIMEOUT at some point.
> For now I'm just interested in knowing if this patch works.
>
>>
>> this 'v2' note doesn't have to go into commit log, IMO.
>>
>
> It's going to be cleaned out as well, just there to explain to Daniel, and the world why
> a second version of the testpatch was created.
all right, thanks ;-)
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)
Powered by blists - more mailing lists