This sounds like it could help with some of the problems I have seen.You might want to pull the latest BK code from my trees, there have been some stall-related changes recently. (Thanks to Pat LaVarre and Alan Stern for helping sort this out, and I suspect they may be able to provide further illumination...) The updates weren't in BK 24 hours ago.
Very briefly: BBB stalls IN endpoints in certain cases, for example:
- Host requests MODE_SENSE_10 and request 28 bytes - But the device only has 20 bytes, so it (a) writes 20 bytes (b) stalls (c) writes 13 byte CSW - Then the host (a) reads the 20 bytes (short transfer); (b) reads a stall (b') clears halt feature on that IN endpoint (c) reads 13 byte CSW
Does it clear that software settable bit when it's latched? I'd hope so;
No, if it did I don't think there would be a problem.
AFAIK clear_feature does not clear any FIFOs.and likewise, I'd hope that the clear_feature isn't clearing anything else except toggle. (Like the FIFO holding the 13 bytes of CSW...)
I'm not quite clear what the problem is here -- latch-without-clear? Can you detect whether a STALL was sent? Does it matter whether there was data in the FIFO before STALL was set ... or when it was cleared?
No, I can't detect whether the stall was sent. I don't think whether there is data in the FIFO affects it (there is no mention of FIFOs being affected by stall in the manual).
Hmm, can you see if implementing that revised usb_ep_set_halt() behavior affects this behavior?
I will try it today.
Here is the relevant section from the device manual, it may explain the situation more clearly:
"18.6.2 Forcible Stall by Application
The application uses the EPSTL register to issue a stall request for the USB function module. When the application wishes to stall a specific endpoint, it sets the corresponding bit in EPSTL (1- 1 in figure 18.13). The internal status bits are not changed at this time. When a transaction is sent from the host for the endpoint for which the EPSTL bit was set, the USB function module references the internal status bit, and if this is not set, references the corresponding bit in EPSTL (1-2 in figure 18.13). If the corresponding bit in EPSTL is set, the USB function module sets the internal status bit and returns a stall handshake to the host (1-3 in figure 18.13). If the corresponding bit in EPSTL is not set, the internal status bit is not changed and the transaction is accepted.
Once an internal status bit is set, it remains set until cleared by a Clear Feature command from the host, without regard to the EPSTL register. Even after a bit is cleared by the Clear Feature command (3-1 in figure 18.13), the USB function module continues to return a stall handshake while the bit in EPSTL is set, since the internal status bit is set each time a transaction is executed for the corresponding endpoint (1-2 in figure 18.13). To clear a stall, therefore, it is necessary for the corresponding bit in EPSTL to be cleared by the application, and also for the internal status bit to be cleared with a Clear Feature command (2-1, 2-2, and 2-3 in figure 18.13)."
Julian
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
