On Fri, Aug 13, 2010 at 06:24:37PM +0200, Hans Petter SELASKY wrote:
> Hi Greg,
>
> We have been thinking about various ways to solve this problem.
> Another way is to re-program then endpoint number to an invalid
> endpoint, but that will only work as long as there is an unused
> endpoint. It appears that the host mode has not been too well tested
> on the MUSB chips. The existing code works because classes like the
> mass storage host driver don't cancel URB's, but rather wait for them
> to complete or timeout. We've seen this issue when testing the USB
> modem host class on Linux using an embedded board, that if the peer is
> not fast enough to read the TX'ed data, we get in the situation where
> the already existing warning triggers during modem port close, and the
> chip goes into a non-responding state. We have not been able to get
> any confirmation from hardware people about this issue.
How about we wait until you do get confirmation from the hardware
people? That would make more sense, right?
> Yes, it's bad to affect all Linux USB users.
That's my main worry.
> Another way is to have an
> USB API where we can set a bit in the USB-device-map bit-array when we
> are attaching the MUSB driver, so that the Linux USB stack always sees
> address X, like in use. That would probably be better, but adds more
> code. Could you add such an API to the USB core. For example:
>
> int
> usb_reserve_bus_address(bus, addr)
> {
> ...
> return 0; /* success */
> }
We could, but I'll have to go dig through my usb spec to verify that we
are allowed to do such a thing. For some reason I thought we were
required to support all 128 devices.
> > Pointers to the type of broken hardware
>
> I guess all MUSB hardware running HOST mode up to date has this bug.
Odd that no one has seen this before, isn't it.
thanks,
greg k-h
--
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
