While testing our host system using Microsoft's usb stack against our
gadget for various BESL values, we found an issue with their usb stack
when the recommended baseline BESL value is 0 (125us) or when the deep
BESL is 1 or less. The Windows host will issue a usb reset immediately
after it receives the extended BOS descriptor and the enumeration will
fail after a few attempts.
To keep compatibility with Microsoft's host usb stack, let's workaround
this issue by using the recommended baseline BESL of 1 (or 150us)
and clamp the deep BESL value within 2 to 15.
This was tested against Windows 10 build 18956.
Signed-off-by: Thinh Nguyen <thi...@synopsys.com>
---
changes in v2:
- Add comment in code for the new change
drivers/usb/dwc3/gadget.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 7b58e0e1e438..3754bffb378c 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2083,9 +2083,19 @@ static void dwc3_gadget_config_params(struct usb_gadget
*g,
/* Recommended BESL */
if (!dwc->dis_enblslpm_quirk) {
- params->besl_baseline = 0;
+ /*
+ * If the recommended BESL baseline is 0 or if the BESL deep is
+ * less than 2, Microsoft's Windows 10 host usb stack will issue
+ * a usb reset immediately after it receives the extended BOS
+ * descriptor and the enumeration will fail. To maintain
+ * compatibility with the Windows' usb stack, let's set the
+ * recommended BESL baseline to 1 and clamp the BESL deep to be
+ * within 2 to 15.
+ */
+ params->besl_baseline = 1;
if (dwc->is_utmi_l1_suspend)
- params->besl_deep = min_t(u8, dwc->hird_threshold, 15);
+ params->besl_deep =
+ clamp_t(u8, dwc->hird_threshold, 2, 15);
}
/* U1 Device exit Latency */
--
2.11.0
