On Sat, 13 Apr 2013, victor yeo wrote: > > The same thing happened when the 0xA1 command was received: > > > >> g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12, Hi=512 > >> g_file_storage gadget: bulk-in, length 0: > >> [start_transfer] 43425355 12 > >> ept1 in queue len 0x0, buffer 0xc12ac000 > >> g_file_storage gadget: bulk-in set halt > >> kagen2_set_halt 1 1 > > > > Right here, a STALL packet should have been sent. It wasn't. > > > >> g_file_storage gadget: sending command-failure status > >> g_file_storage gadget: sense data: SK x05, ASC x20, ASCQ x00; info x0 > >> g_file_storage gadget: bulk-in, length 13: > >> 00000000: 55 53 42 53 12 00 00 00 00 02 00 00 01 > >> [start_transfer] 53425355 12 > >> ept1 in queue len 0xd, buffer 0xc133c000 > >> 0: 0x53425355 > >> 4: 0x12 > >> 8: 0x200 > >> bulk_in_complete --> 0, 13/13 > > > > Instead this packet was sent. > > > > Alan Stern > > Thanks! This packet is the CSW to the unknown SCSI command 0xa1. So it > should not be sent at all, and the UDC driver should send the STALL > packet instead of this CSW? No. As long as the Halt feature is set for the bulk-in endpoint, the UDC should send STALL packets. When the host clears the Halt feature, then the UDC should send the CSW packet. > Just curious, after this 0xa1 is received and bulk-in endpoint is > halted. The Linux host tries to send TEST_UNIT_READY command, and UDC > driver could not receive it because endpoint is halted and in reset > condition. That sounds very wrong. The bulk-IN endpoint was halted, but the TEST UNIT READY command is sent to the bulk-OUT endpoint. There should be no problem receiving it. > Seems like the set Halt feature is working (but STALL > packet is not sent). Maybe the UDC driver is halting the wrong endpoint. 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
