Hi, On 11/10/2015 05:25 PM, Oliver Neukum wrote:
Hi, we have a report about a device returning IU_ID_RESPONSE to uas_stat_cmplt(). It seems to me that this is in principle a valid response to a command.
Ugh, it has been a while since I last worked on this. IIRC IU_ID_RESPONSE is only used to indicate errors at the transport layer, like an invalid lun or too high tag. I've seen this once but then it was due to a problem at another layer. What is the command being send before the IU_ID_RESPONSE? The trick may be to blacklist that command, IIRC that is how I fixed this last time, I think the US_FL_NO_REPORT_OPCODES quirk fixed it back then. It may have also been related to the device responding with an old style (pre final standard) sense iu, I've seen that happen with some really old enclosures in some error conditions, but we blacklisted all those, so the report for the non standard compliant sense iu-s was removed: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/storage/uas.c?id=5ad22cfc13399cc46267e5685769d6e7a0bbe163 > Is the absence of an answer to it in uas_stat_cmplt() intentional? Not sure what you mean with the "an answer" bit, AFAIK once we get a response iu the command is complete (failed) from the transport / target pov. But yes the not doing anything other then setting an error and reporting it upward is intentional. I hope this helps, and sorry that I do not remember the exact conditions under which I saw a response iu myself, but under normal conditions we should never get one. Regards, Hans -- 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
