On Fri, 14 Mar 2014, David Mosberger wrote: > 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". But it isn't. When a device sends a NAK, it doesn't mean "I don't know what to do with this". It means "I'm not ready to receive (or send) this data", or (in the status stage of a control transfer) "I'm not finished processing this data". I'm serious. A NAK response in a bulk-OUT transaction means that the device simply threw away the data -- it didn't even store the data in an internal buffer, let alone try to parse the data and decide that it didn't understand something. If a device wants to say "I don't know what to do with this", it sends a STALL or uses some other class-specific mechanism. > 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. There was no offending command. In fact, there was no command at all, right? The data got sent from the wrong FIFO, so you ended up sending a packet containing only 0's, not a valid CBW. Now, I'm not saying what the device did was correct. According to section 6.6.1 of the Bulk-Only Transport Mass Storage spec, when the device expects a CBW packet but gets something else, it is supposed to accept the packet (ACK, not NAK), stall the bulk-IN endpoint, and either stall or accept and discard all further bulk-OUT data. > > 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. NAKs mean the device isn't ready to accept the data the host is sending. It could be because of a bug in the device's firmware, or it could be because the host violated the expected protocol somehow. Alan Stern -- 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
