4.14-stable patches

added patches:
	usb-dwc3-core-defer-probe-on-ulpi_read_id-timeout.patch

diff --git a/queue-4.14/series b/queue-4.14/series
index 32c035f55d3935cbfad5b4895a8e741b66c33446..d95882e64ae9e5599f3190e7048ea5b870f362b0 100644 (file)
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -256,3 +256,4 @@ asoc-rockchip-spdif-add-missing-clk_disable_unprepar.patch
 asoc-rt5670-remove-unbalanced-pm_runtime_put.patch
 pstore-switch-pmsg_lock-to-an-rt_mutex-to-avoid-prio.patch
 pstore-make-sure-config_pstore_pmsg-selects-config_r.patch
+usb-dwc3-core-defer-probe-on-ulpi_read_id-timeout.patch

diff --git a/queue-4.14/usb-dwc3-core-defer-probe-on-ulpi_read_id-timeout.patch b/queue-4.14/usb-dwc3-core-defer-probe-on-ulpi_read_id-timeout.patch
new file mode 100644 (file)
index 0000000..593d037
--- /dev/null
+++ b/queue-4.14/usb-dwc3-core-defer-probe-on-ulpi_read_id-timeout.patch
@@ -0,0 +1,58 @@
+From 63130462c919ece0ad0d9bb5a1f795ef8d79687e Mon Sep 17 00:00:00 2001
+From: Ferry Toth <ftoth@exalondelft.nl>
+Date: Mon, 5 Dec 2022 21:15:27 +0100
+Subject: usb: dwc3: core: defer probe on ulpi_read_id timeout
+
+From: Ferry Toth <ftoth@exalondelft.nl>
+
+commit 63130462c919ece0ad0d9bb5a1f795ef8d79687e upstream.
+
+Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral
+if extcon is present"), Dual Role support on Intel Merrifield platform
+broke due to rearranging the call to dwc3_get_extcon().
+
+It appears to be caused by ulpi_read_id() masking the timeout on the first
+test write. In the past dwc3 probe continued by calling dwc3_core_soft_reset()
+followed by dwc3_get_extcon() which happend to return -EPROBE_DEFER.
+On deferred probe ulpi_read_id() finally succeeded. Due to above mentioned
+rearranging -EPROBE_DEFER is not returned and probe completes without phy.
+
+On Intel Merrifield the timeout on the first test write issue is reproducible
+but it is difficult to find the root cause. Using a mainline kernel and
+rootfs with buildroot ulpi_read_id() succeeds. As soon as adding
+ftrace / bootconfig to find out why, ulpi_read_id() fails and we can't
+analyze the flow. Using another rootfs ulpi_read_id() fails even without
+adding ftrace. We suspect the issue is some kind of timing / race, but
+merely retrying ulpi_read_id() does not resolve the issue.
+
+As we now changed ulpi_read_id() to return -ETIMEDOUT in this case, we
+need to handle the error by calling dwc3_core_soft_reset() and request
+-EPROBE_DEFER. On deferred probe ulpi_read_id() is retried and succeeds.
+
+Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
+Cc: stable@vger.kernel.org
+Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
+Link: https://lore.kernel.org/r/20221205201527.13525-3-ftoth@exalondelft.nl
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/dwc3/core.c |    7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/dwc3/core.c
++++ b/drivers/usb/dwc3/core.c
+@@ -801,8 +801,13 @@ static int dwc3_core_init(struct dwc3 *d
+ 
+       if (!dwc->ulpi_ready) {
+               ret = dwc3_core_ulpi_init(dwc);
+-              if (ret)
++              if (ret) {
++                      if (ret == -ETIMEDOUT) {
++                              dwc3_core_soft_reset(dwc);
++                              ret = -EPROBE_DEFER;
++                      }
+                       goto err0;
++              }
+               dwc->ulpi_ready = true;
+       }
+