> -----Original Message----- > From: David Brownell [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 29, 2007 4:38 AM > To: Alan Stern > Cc: Pandita, Vikram; USB development list; [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] Scenario: usbtest test-14 failure: MUSBHDRC > + Netchip2280 > > > > > > > > (**) 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.
The discussion on PING should be based on the Spec Errata - errata-092800-1207001.pdf, as the figure 8-27 is wrong in the 2.0 sepc: Section Incorrect Figure 8-27 (Host High-speed Bulk OUT/Control Ping State Machine): Page 8. >From this figure, the PING is related to: OUT, SETUP (Do_token1 --> Do_data1) The confusion is: if there is NYET response from a device to a PING, then should the HOST interpret that as : a) next OUT cannot be sent yet or b) the device is not in a ready state and so keep Pinging till ACK and then start next transaction >From the corrected figure 8-27 it is clear that SETUP can still be sent irrespective of the PING state of the device. So (a) could be the right interpretation. > > > > > > Re-read that please ... "must". That's what getting a NYET means. > > > > Here's the exact text from the spec: > > > > If the endpoint instead responds to the OUT/DATA transaction with > > a NYET handshake, this means that the endpoint accepted the data > > but does not have room for another wMaxPacketSize data payload. > > The host controller must return to using a PING token until the > > endpoint indicates it has space. > > > > This clearly indicates, even though it doesn't say so explicitly, > > Disagree. It says explicitly that it "must" return to PING. It does > not create an exception like the one you ascribe to that text. > > (Note by the way that "wMaxPacketSize" is superfluous. If it's ready > for any data at all, it's ready for that much.) > > > > that the > > host controller must return to using a PING token _before sending the > next > > OUT/DATA transaction_ until the endpoint indicates it has space. > > And implementors are certainly allowed to use the same FIFO for IN > transfers, > which could have the same "fifo must be ready" constraint as OUT ones do. > > > > The > > entire discussion of the PING protocol is centered around the idea of > > improved handling of OUT transfers; PINGs aren't needed before IN or > SETUP > > transactions at all. > > No, but PINGs *are* needed to finish processing an OUT transfer. > Which is what the text says... > > > > After all, what reason could there be for sending a PING before an > > IN/DATA? PING asks whether the endpoint has space to store a new > > wMaxPacketSize data payload, but with IN transfers the endpoint doesn't > > have to store anything. > > What reason? Well, as noted above, the spec is written so hosts "must" > send the PING. Accordingly, peripherals are allowed to rely on that. > > For example, trusting that the FIFO empties before control IN/STATUS > packets start to arrive. > > > > > > 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. > > > > No. If a PING is due, it means that the data already sent was received > > correctly and hence the data stage _is_ complete. You can see it in the > > section I quoted above: "... this means that the endpoint accepted the > > data...". > > You're using a different definition of complete than I am. I'm using > the same definition that a normal bulk OUT would use: ready to accept > one more OUT packet. (ISTR that peripherals are expected to handle any > number of zero length OUT packets at the same point they're expected > to start handling the status stage, for example ...) > > > > > 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. > > > > I agree about the meaning of "must"; the question is: must do what? > > The text seems clear to me: must PING until the endpoint has space. > > > > I claim the intention of the spec is that the host must send a PING > before > > starting another OUT/DATA transaction. > > Thing is, you're inferring an "intention" that's not written, while > ignoring the text that *IS* written. > > Given a spec, standard practice is to stick to what's written, unless > it's ambiguous. (Here, it isn't.) If there's ambiguity, then it's > fair to use "intention" to make an educated guess ... but then also > update the spec to remove the ambiguity, once everyone agrees on how > that should be resolved. > > > > You seem to think it means the host must send a PING > > Period, no matter what, since that's clearly what the spec says. > > > > before starting the IN/DATA transaction for the > > status stage. I don't see how we can determine what the authors of the > > spec really had in mind other than by asking them... but my > interpretation > > makes more sense. > > See above. > > > > Well, the patch is a separate question. Thinking about it some more, I > > doubt it will actually fix the problem. In fact, my best guess is that > > for some reason the net2280 doesn't set the DATA_IN_TOKEN_INTERRUPT flag > > when the IN token arrives. Maybe some sort of low-level hardware timing > > issue. > > Like ... maybe the NetChip folk took the USB spec at its word? :) > > Or alternatively, some of the recent net2280 patches broke some of > the more subtle race-avoidance logic in that driver. As I mentioned, > I saw something rather fishy go flying by at one point; and that > particular conditional does look fishy lately. > > - Dave ------------------------------------------------------------------------- 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
