On Wed, May 20, 2020 at 02:25:36PM -0400, Alan Stern wrote: > On Wed, May 20, 2020 at 01:05:50PM -0500, Bin Liu wrote: > > On Wed, May 20, 2020 at 12:40:55PM -0400, Alan Stern wrote: > > > > > Then do you think we should change the API? > > > > > > > > > > Right now it's a little too complicated. There's no real reason for > > > > > EPROTO, EILSEQ, and ETIME to be different codes. And now you seem to be > > > > > suggesting that we should fold them all into ESHUTDOWN. > > > > > > > > I haven't studied all the USB error code enough to suggest this. I am > > > > only changing to ESHUTDOWN in musb driver because I know this 3-strikes > > > > error should only be caused by USB device disabled, which is the > > > > definition of ESHUTDOWN in error-code.rst. > > > > > > You should spend a little time studying the error-codes document. > > > EPROTO, EILSEQ, and ETIME describe different kinds of errors that all > > > fall into the 3-strikes category. > > > > But not all device drivers, except the 3 I found, treat EPROTO as fatal, > > and I cannot fix it in all the device drivers. The only thing I can do > > at this moment is changing the MUSB HCD driver to return ESHUTDOWN which > > still follows the document, kind of. > > Think long-term. Yes, for now you're focused on changing the MUSB HCD. > But what should happen in the future? > > At some point we all need to stop reacting and start making some > deliberate plans. This issue is bigger than one patch or one driver. Yes, the issue big, not all device drivers treat the urb error status properly. As the case #3 I mentioned earlier, even MUSB HCD returns ESHUTDOWN, the interrupt storm still happens. Unfortunately before I located the offending device driver, the remote setup is gone... I agree with you, we probably should simply the number of the error code based on the real usecases and the handlings in device drivers. -Bin.
