On Wed, Sep 24, 2014 at 12:19:13PM -0500, Felipe Balbi wrote: > Hi, > > On Wed, Sep 24, 2014 at 11:20:31AM -0500, Felipe Balbi wrote: > > > > > > Therefore stalling is appropriate. Why it causes it problem for > > > > > > your > > > > > > system is a different matter. Is your UDC hardware capable of > > > > > > halting > > > > > > bulk endpoints? > > > > > > > > > > yeah, that part is just fine; I also verified with my sniffer that > > > > > bulk > > > > > halt is happening as it should. The problem, however, is that after > > > > > that > > > > > halt condition happens, host (same board has xhci too, Linux 3.17-rc5) > > > > > issues a reset recovery > > > > > > > > It shouldn't; there's no reason for it to do so. Unless something > > > > else is going wrong on the host side. Have you tried capturing a > > > > usbmon trace on the host? > > > > > > I'll capture usbmon and send here shortly. > > > > here it is... Interesting part starts at line 73 (114 on this email) > > where the data transport received EPIPE (due to Stall). This time > > however, I was eventually able to talk to the device and managed to > > issue quite a few writes to it. > > so here's sequence of events so far: > > - Enumration goes fine > - Get Max Lun -> 0 (single lun) > - Inquiry -> Passed > - Test Unit Ready -> Failed > - Request Sense (Unit Attention) -> Passed > - Test Unit Ready -> Passed > - Mode Sense -> Stall of Data transport. > - Clear Endpoint Feature (HALT) EP1 IN > - After clear feature, a 16 bulk in completes. Shouldn't gadget > driver have cancelled that ? > - Bus reset
looking into the SCSI glue, it seems like scsi is calling ->eh_bus_reset_handler() instead of ->eh_device_reset_handler(). Digging a little more. -- balbi
signature.asc
Description: Digital signature
