hi alan: 2014-12-19 23:20 GMT+08:00 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Fri, 19 Dec 2014, vichy wrote: > >> hi all: >> For HW bug, we have to mdelay(100) in getting root hub port status. > > That's quite a bug! 100 ms is a very long delay. With a bug that big, > it's questionable whether the hardware will work correctly at all. > >> But it suffer system performance. >> (The place we need to add is like below) >> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c >> index 388cfd8..9a6b841 100644 >> --- a/drivers/usb/host/xhci-hub.c >> +++ b/drivers/usb/host/xhci-hub.c >> @@ -760,6 +760,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 >> typeReq, u16 wValue, >> retval = -ENODEV; >> break; >> } >> + mdelay(100); >> status = xhci_get_port_status(hcd, bus_state, port_array, >> wIndex, temp, flags); >> if (status == 0xffffffff) >> >> >> Then I try to use msleep(100) but I found hub_port_status will first >> mutex_lock(&hub->status_mutex); then calling get_port_status. >> That mean the deadlock may happen. > > No it doesn't. Why it doesn't? from the source, the get_port_status did called in critical section protected by hub->status_mutex. And msleep is not allowed in critical section. appreciate your help, -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
