On Tue, 19 May 2009, Greg KH wrote: > On Tue, May 19, 2009 at 04:08:00PM -0700, Rob Duncan wrote: > > I have a composite device (multiple serial ports) where each serial > > port is controlled by a separate instance of my driver. The driver > > instances all use the default control pipe to make configuration > > changes on the device via usb_control_msg(). Are there any special > > locking requirements that I need to take into account so that the > > driver instances do not interfere with each other when they use this > > routine? I have been assuming that the answer to that question is > > "No!", but I'm running into some surprising (to me) behavior. The answer _is_ "No!", as far as the host side is concerned. The device may have its own requirements. > > It seems that if several drivers concurrently make several > > configuration parameter changes via usb_control_msg() I occasionally > > see some control transfers duplicated on the bus, and some missing > > (each duplicate appears to have taken the place of a transfer from > > another driver instance). I have added logging to my driver and see > > the interleaved requests from the different driver instances, but the > > trace I obtain with the CATC bus analyzer doesn't match with my logs. > > That sounds pretty strange. Any logs we can look at? In addition to the driver and CATC logs, a usbmon log would be helpful. That sort of behavior should never happen; if it does then it's a bug. > You might need to "merge" your ports into one driver, so you can > properly handle the locking for the control endpoint. Or provide a > function that grabs a device-specific lock, that all of the drivers call > into, that will serialize things properly. That's probably the simplest > and is probably what the device is expecting. Could be, especially if some of the communication involves a sequence of control requests. Although the individual requests from the different driver instances are serialized, there's nothing to prevent the requests in one sequence from intermingling with those in another. 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
