Alan, On Fri, Mar 14, 2014 at 8:02 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 13 Mar 2014, David Mosberger wrote: > >> To answer my own question: it appears that USB peripherals return NAKs >> not only when the peripheral is not ready to accept the data, but also >> when the peripheral doesn't know what to do with the data. > > No, that's not right. If the device doesn't know what to do with the > data (for example, if it doesn't recognize a particular SETUP request), > it replies with a STALL. Please re-read my statement again. I said that infinite NAKs is one way for a peripheral to say, "I don't know what to do with this". I didn't say it's the only way to handle errors. I certainly would have much preferred to get a STALL for my situation because it'd have made it very clear what the offending command was. > Probably what happens is that the device doesn't queue an internal > request for an OUT transfer until it knows that it needs some data. > Without a request queued, the device's USB controller doesn't have > any place to store the data sent by the host computer, so it NAKs the > transfer. > > It really is saying "I'm not ready to accept this data". Sure, that sounds very plausible. I didn't say the device was doing anything wrong. I just have seen several other questions from developers about infinite NAKs but never an answer as to what would cause that, so I wanted to explain it for the benefit of others. --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- 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
