> > Actually there's no technical reason device shouldn't handle multiple > > queued control transfers, and I could see it happening in cases > > where more than one driver needs to talk to the device at a time. > > > > Whether drivers want to impose a exclusionary policy about > > control transfers is orthogonal to mutual exclusion for the use > > of such a buffer. > > Yes, but you're making this complicated now.
Nope, it was already that complex ... :) > Allocate devrequest when you allocate the device and it'll work in 99% > of the cases people care about, which is 100% of existing drivers. One suspects it's not common, but that can't be relied on. If anyone makes such a patch, they shouldn't forget to add some sort of locking around use of that buffer. It suspect it'd be fine if only usb_control_msg() used it, and locked accordingly. That call path already needs to block. Clearly anyone queuing async control messages isn't going to be able to use such a built-in buffer. > BTW - Another 2.5 thing I'd like to see is someone scold me for the case > of the name and elements of devrequest and then change it to be > similar to the USB specs and the rest of the structures in the Linux > USB code :) Consider yourself scolded then ... and submit the patch when ready! :) - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
