On Thu, 7 Jun 2012, Balakumar RAJENDRAN wrote: > On SMP systems there is a synchronization issue in the gadget > serial driver which potentially causes a packet swap on some > occasions. In the gadget serial driver implementation, a transfer > is queued to the controller on the following two occasions. > > 1. Application requesting to send data through gadget serial driver: > 2. Previously scheduled transfer is complete and a new transfer is > triggered from the callback function: > > On SMP systems, sometimes there is a packet swap since the port lock > is being dropped briefly during queueing. On some occasions, as both > the completion routine and the application are trying to queue the data > at the same time, due to the lock being dropped, the packets gets > swapped before they get queued to the endpoint. As far as I know, the Gadget API does not guarantee that completion handlers will be called in a separate thread from submissions. This means that requests should not be submitted while holding a lock that the completion routine will acquire. You should find a better way of synchronizing the two submission paths. For example, have a single subroutine do all the packet submissions. If the previous submission is still in progress, don't start a new one. And whenever a submission finishes, see if another submission is needed. 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
