Re: usbtest test-14 failure: MUSBHDRC + Netchip2280
Alan Stern <[email protected]>
| Newsgroups | gmane.linux.usb.devel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 26 Mar 2007, Pandita, Vikram wrote:
> On usbtest 14, the IN token sent by MUSBHDRC is being STALL'ed instead
> of being NAK'ed by the Netchip device.
>
> Interestingly, if I enable some logs on Netchip driver or Host side, the
> test 14 passes. This points to some timing related issue. Is it that
> Netchip needs some delay in handling consecutive control transfers?
>
> I could narrow down to the following netchip code that sets the STALL.
> Is that expected behaviour on netchip side?
>
>
> --- a/drivers/usb/gadget/net2280.c 2007-03-23 16:40:44.000000000 +0530
> +++ b/drivers/usb/gadget/net2280.c 2007-03-23 17:19:21.000000000 +0530
> @@ -2204,12 +2206,16 @@ static void handle_ep_small (struct net2
> && req
> && req->req.actual ==
> req->req.length)
> || !req) {
> +printk("\n-->STALL\n");
> +#if 0
> ep->dev->protocol_stall = 1;
> +
> set_halt (ep);
> ep->stopped = 1;
> if (req)
> done (ep, req, -EOVERFLOW);
> req = NULL;
> +#endif
> }
> }
> }
This code runs when the Netchip receives an OUT or PING token, not an IN
token. I doubt that it is related to the delay between control transfers.
If the MUSBHDRC really did send an extra OUT token, then the bug is in the
MUSBHDRC. If it really sent an IN token but the Netchip set the flag for
an OUT token, then the bug is in the Netchip.
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel