We are seeing relatively high interrupt latencies due to usb_sg_wait() calling usb_submit_urb() with interrupts disabled (as a result of its spin_lock_irq() call).
As far as I can see, io->lock protects io->status and it's not really necessary to hold the lock (or disable interrupts) during the usb_submit_urb() call. Note that the current code doesn't protect against multiple concurrent calls to usb_sg_wait(): a second caller of usb_sg_wait() could acquire io->lock when the first caller drops it after calling usb_submit_urb() and then it could resubmit the same URBs before the first caller gets a chance to update io->status. This is perhaps an outright bug? Am I missing something? --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
