[haiku-commits] Re: r41658 - haiku/trunk/src/add-ons/kernel/busses/usb
- From: Jérôme Duval <korli@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 23 May 2011 10:11:18 +0200
2011/5/23 mmlr@xxxxxxxx <mmlr@xxxxxxxx>:
> And for completeness; Sorry for the spam:
That's fine!
>
> On May 22, 2011 at 11:47 PM "mmlr@xxxxxxxx" <mmlr@xxxxxxxx> wrote:
>> Since the Linux code is rather hard to understand, you can very easily find
>> different values that seemingly are put to use. However for this actual case
>> (not the resume or wake cases) it uses exactly the 50ms spec value as a
>> minimum
>> (http://lxr.linux.no/linux+v2.6.39/drivers/usb/host/ehci-hub.c#L1096). The
>> actual wait time depends on when the caller issues the GetPortStatus, which
>> likely boosts that timing a little.
>
> Looking through where this is all put to use:
> http://lxr.linux.no/linux+v2.6.39/drivers/usb/core/hub.c#L2731
>
> Values coming from:
> http://lxr.linux.no/linux+v2.6.39/drivers/usb/core/hub.c#L2035
>
> The delay is originally the short delay (10ms), then for root hubs is boosted
> to
> the root port delay (50ms) and for low speed devices to the long delay
> (200ms).
> We might want to make the distinction for low-speed devices which can happen
> in
> the case where an EHCI root hub has a transaction translator built in.
IMO the low speed device doesn't interest EHCI as it doesn't reset the
port in this case.
>
> What might also be interesting is that they actually try longer delays if the
> shorter ones didn't work:
> http://lxr.linux.no/linux+v2.6.39/drivers/usb/core/hub.c#L2040
Right. In my case, the device disappeared (CONNECT = 0) if the wait
was too long.
>
> That'd probably make sense to implement for us as well as it is the most
> flexible. Note that they only ever wait for up to "hub reset timeout" which is
> 500ms.
Interesting as I didn't search enough to find these values. It might
be a good idea to check for eventual regressions then.
Bye,
Jérôme
Other related posts: