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. > Is there any better way to do so? Consider other chips that don't have this hardware bug. Is there any reason to make those systems wait 100 ms when they don't need to? That's what your patch would do. Alan Stern -- 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
