> > > > It doesn't make sense to me that if more delays are added in > > > > the kernel code, userland needs to see even more. > > > > > > I agree, but Olaf and others prove that this works. > > > > There was that hypothesis that it's really control traffic > > interference ... I notice that usb_control_msg() chose > > against the "keep the setup data in struct usb_device > > and lock it with a semaphore" strategy (it kmallocs > > the setup buffer), so I could see how that'd happen. > > It's always been this way, right?
No, the kmalloc() is newish. Previously it did stack allocation (bad since dma-from-stack isn't sure to work on all systems). I wonder whether adding semaphore plus eight bytes of buffer (vs just semaphore) would even make the "struct usb_device" objects go into a different kmalloc cache ... :) > > ... > > > > I think the best that can be done for now would be a > > hack: add a lock in usb_device that must be held > > by whoever submits a control request, and released > > when that request completes. The non-hack solution > > is to support control queuing in all HCDs. > > > > What kind of lock? Maybe that binary semaphore. > > Code that needs to issue control requests in_interrupt() > > would need to be modified, as would usb_control_msg(). > > Yes, this would be the best way. I don't think it's a hack, as some > drivers (like the usb-storage one) have said that they really need to > lock the control pipe for a while to prevent things from happening out > of order (for very dumb devices.) Seems like a hack to me since it pessimizes driver performance for conforming devices in favor of an unknown (and presumed small :) set of nonconforming ones. Plus, I seem to recall Matt saying that the original motivation was a reading that the storage spec required that -- but a later reading said it didn't require that. That said -- I think we'd be interested in a patch prepared to implement that "hack", since it's the best that's likely to show up near-term. I presume Olaf (and others) could verify whether it really solved the problem. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
