hc
2023-12-11 d2ccde1c8e90d38cee87a1b0309ad2827f3fd30d
kernel/drivers/usb/dwc2/core_intr.c
....@@ -288,14 +288,9 @@
288288
289289 /*
290290 * Need to schedule a work, as there are possible DELAY function calls.
291
- * Release lock before scheduling workq as it holds spinlock during
292
- * scheduling.
293291 */
294
- if (hsotg->wq_otg) {
295
- spin_unlock(&hsotg->lock);
292
+ if (hsotg->wq_otg)
296293 queue_work(hsotg->wq_otg, &hsotg->wf_otg);
297
- spin_lock(&hsotg->lock);
298
- }
299294 }
300295
301296 /**
....@@ -404,7 +399,6 @@
404399 static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
405400 {
406401 int ret;
407
- struct device_node *np = hsotg->dev->of_node;
408402
409403 /* Clear interrupt */
410404 dwc2_writel(hsotg, GINTSTS_WKUPINT, GINTSTS);
....@@ -449,15 +443,15 @@
449443 dwc2_writel(hsotg, pcgcctl, PCGCTL);
450444
451445 /*
452
- * It is a quirk in Rockchip RK3288, causing by
453
- * a hardware bug. This will propagate out and
454
- * eventually we'll re-enumerate the device.
455
- * Not great but the best we can do.
446
+ * If we've got this quirk then the PHY is stuck upon
447
+ * wakeup. Assert reset. This will propagate out and
448
+ * eventually we'll re-enumerate the device. Not great
449
+ * but the best we can do. We can't call phy_reset()
450
+ * at interrupt time but there's no hurry, so we'll
451
+ * schedule it for later.
456452 */
457
- if (of_device_is_compatible(np, "rockchip,rk3288-usb")) {
458
- /* FIXME: wkp_timer might run early than phy_rst_work */
459
- schedule_work(&hsotg->phy_rst_work);
460
- }
453
+ if (hsotg->reset_phy_on_wake)
454
+ dwc2_host_schedule_phy_reset(hsotg);
461455
462456 mod_timer(&hsotg->wkp_timer,
463457 jiffies + msecs_to_jiffies(71));