> > > > > > (**) 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. > > 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
