[PATCH v2 1/2] usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT

[Marek Vasut]

On 9/12/22 15:37, Patrick DELAUNAY wrote:
> Hi,

Hi,

> On 9/9/22 14:24, Marek Vasut wrote:
>> On 9/9/22 11:45, Patrick Delaunay wrote:
>>> Add a new CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to increase the
>>> HUB_DEBOUNCE_TIMEOUT value, for example to 2s because some usb device
>>> needs around 1.5s or more to make the hub port status to be
>>> connected steadily after being powered off and powered on.
>>>
>>> This 2s value is aligned with Linux driver and avoids to configure
>>> "usb_pgood_delay" as a workaround for connection timeout on
>>> some USB device; normally the env variable "usb_pgood_delay" is used
>>> to delay the first query after power ON and thus the device answer,
>>> but this variable not used to increase the connection timeout delay.
>>
>> I realized this has one problem -- what happens if you have multiple 
>> USB controllers in your system ? The answer is, all of them are 
>> affected by the increased delay, possibly even those which do not 
>> require the extra delay.
>>
>> Would it be possible to configure this per-controller (or should this 
>> even be per-device?) in DT ? In fact, I wonder whether this is not 
>> becoming a Vbus regulator ramp-up time kind of delay here ?
> 
> 
> Yes, but I don't think, it is blocking.
> 
> This timeout will be common for all the USB HUB in the system, as it is 
> done in Linux kernel.

I just realized this is not the same delay as the usb_pgood_delay, right ?

This is actually the maximum wait for a device to start communicating, 
i.e. even if this timeout is set to a very high value, most devices will 
not take that long and will start communicating in shorter time anyway, 
so the time of completion for e.g. '=> usb reset' is not affected by 
this change on very much all systems, correct ?