Re: [linux-usb-devel] [PATCH] fix some hubs and hid devices at startup

[David Brownell <david-b@pacbell.net>]

> > > > 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



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel