On Wednesday 28 March 2007 9:04 am, Alan Stern wrote:
> On Wed, 28 Mar 2007, David Brownell wrote:
>
> > On Wednesday 28 March 2007 2:29 am, Pandita, Vikram wrote:
> > >
> > > > (**) 8.5.1 in the USB 2.0 spec says that after a NYET handshake,
> > > > "the host controller must return to using a PING token until the
> > > > endpoint indicates it has space".
> > > >
> > > > Clearly, the HDRC did not issue any PINGs ... it just went right
> > > > to the status handshake. Fishy, and quite possibly something
> > >
> > > The PING flow-control is only for the OUT tokens.
> > > So Host should send PING only if next OUT token is to be sent.
> >
> > That "must" language is unambiguous: PING "must" be sent.
> > There is no "should" in that paragraph of the spec.
Re-read that please ... "must". That's what getting a NYET means.
> > Read it this way: the host must send PING until it reports
> > that the next data token may be sent to that endpoint. The
> > fact that it will be a zero length packet is irrelevant, as
> > is the fact that this is a control endpoint (the data stage
> > works like normal BULK data, where that can't happen) so it
> > will be an IN token; in either case, the FIFO may still not
> > be ready.
>
> That's not right. Here's what the spec says (section 8.5.1):
>
> High-speed devices must support an improved NAK mechanism for Bulk
> OUT and Control endpoints and transactions. Control endpoints
> must support this protocol for an OUT transaction in the data and
> status stages.
And ... the OUT/DATA stage can't have completed if a PING was due.
As soon as the OUT/DATA stage completes, then the IN transactions
may do their usual thing, and that different paragraph applies.
> The PING protocol is not supported for IN transactions in control
> transfers -- i.e., not for the status stage of an OUT transfer. You could
> probably deduce this from Figure 8-27, but I have never been able to
> figure out those baroque state transition diagrams.
... right, not required for IN transactions, but the preceding OUT
was still partly pending, so the status stage wasn't ready to begin.
If the OUT were complete, no PINGs would be needed would they?
Show me that's a misreading of the spec, and I'll agree with you.
Specifically, that "must" does not seem amenable to any kind of
misreading. There's no precondition there; not even any kind of
weasel-wording to support ignoring the "must"-PING sentence.
If your proposed patch helps -- ISTR being puzzled by the preceding
changes in that area -- that's fine. But I'll still think the spec
views that packet sequence (PINGs omitted) as an error, and that this
just works around a host side issue.
> --- usb-2.6.orig/drivers/usb/gadget/net2280.c
> +++ usb-2.6/drivers/usb/gadget/net2280.c
> @@ -2200,16 +2200,16 @@ static void handle_ep_small (struct net2
> }
> mode = 2;
> /* an extra OUT token is an error */
> - } else if (((t & (1 << DATA_OUT_PING_TOKEN_INTERRUPT))
> - && req
> - && req->req.actual == req->req.length)
> - || (ep->responded && !req)) {
> - ep->dev->protocol_stall = 1;
> - set_halt (ep);
> - ep->stopped = 1;
> - if (req)
> - done (ep, req, -EOVERFLOW);
> - req = NULL;
> + } else if (t & (1 << DATA_OUT_PING_TOKEN_INTERRUPT)) {
> + if ((req && req->req.actual == req->req.length)
> + || (!req && ep->responded)) {
> + ep->dev->protocol_stall = 1;
> + set_halt(ep);
> + ep->stopped = 1;
> + if (req)
> + done(ep, req, -EOVERFLOW);
> + req = NULL;
> + }
> }
> }
> }
>
-------------------------------------------------------------------------
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
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
