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.
Yes, it's bad to affect all Linux USB users. 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 */
}
> Pointers to the type of broken hardware
I guess all MUSB hardware running HOST mode up to date has this bug.
--HPS @ STE
-----Original Message-----
From: Greg KH [mailto:greg@xxxxxxxxx]
Sent: 13. august 2010 16:58
To: Praveena NADAHALLY
Cc: linux-usb@xxxxxxxxxxxxxxx; STEricsson_nomadik_linux; Linus WALLEIJ; Hans Petter SELASKY
Subject: Re: [PATCH] Workaround for hardware problem in host mode for the MUSB chipset. Add missed TXPKTRDY check.
On Fri, Aug 13, 2010 at 05:44:54PM +0530, Praveena Nadahally wrote:
> From: Hans Petter Selasky <hans.petter.selasky@xxxxxxxxxxxxxx>
>
> FIFOFLUSH is broken when a real packet is in the FIFO. This
> hardware feature only works when the FIFO is empty.
> The workaround described requires limiting the maximum
> number of USB devices to 126, 128 - 2.
Really? That seems like not a very nice thing to do to all Linux users
just for a single piece of broken hardware out there.
Can we get some more information about this hardware problem please?
Pointers to the type of broken hardware and where the change is stated
as a solution is necessary.
> Signed-off-by: Hans Petter Selasky <hans.petter.selasky@xxxxxxxxxxxxxx>
> Signed-off-by: Praveena Nadahally <praveen.nadahally@xxxxxxxxxxxxxx>
> Acked-by: Linus Walleij <linus.walleij@xxxxxxxxxxxxxx>
> ---
> drivers/usb/core/hub.c | 8 ++++--
> drivers/usb/musb/musb_host.c | 45 +++++++++++++++++++++++++++++------------
> 2 files changed, 37 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 84c1897..83f1f50 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1511,12 +1511,14 @@ static void choose_address(struct usb_device *udev)
> * bus->devnum_next. */
> devnum = find_next_zero_bit(bus->devmap.devicemap, 128,
> bus->devnum_next);
> - if (devnum >= 128)
> + /* Due to Hardware bugs we need to reserve a device address
> + * for flushing of endpoints. */
If we really have to do this, I want it explicitly stated exactly what
the broken hardware is that is causing this restriction, and why.
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
