Re: [PATCH] usb: musb: return -ESHUTDOWN in urb when three-strikes error happened

[Bin Liu <b-liu@ti.com>]

On Tue, May 19, 2020 at 04:01:58PM -0400, Alan Stern wrote:
> On Tue, May 19, 2020 at 12:12:55PM -0500, Bin Liu wrote:
> > On Thu, May 14, 2020 at 02:55:49PM -0400, Alan Stern wrote:
> > > On Thu, May 14, 2020 at 12:00:23PM -0500, Bin Liu wrote:
> > > 
> > > > > Still, it's worth pointing out that this change abuses the API (perhaps 
> > > > > mentioning it in a comment).  And it still would be preferable to fix 
> > > > 
> > > > Okay, I will add those notes in comment in v2.
> > > > 
> > > > > the drivers in question, impractical though that may be.  (I have a hard 
> > > > > time believing there are really 500 of them getting this wrong...)
> > > > 
> > > > I am not sure about it either, but yeah it is not practical to fix the
> > > > issue in device drivers. So far I have seen 3 reports of this issue:
> > > > 
> > > > 1. with FTDI usb-serial adapter, the issue is in the usb serial generic
> > > > driver;
> > > 
> > > It shouldn't be hard to fix this.  We don't even need a delayed retry; 
> > > the driver can simply treat -EPROTO as an unrecoverable error, just like 
> > > -ESHUTDOWN.
> > 
> > This is just an example showing that it is not practical to fix the
> > problem in device drivers.
> > 
> > BTY, I just briefly searched the drivers/ folder, there are only three
> > drivers handle -EPROTO specifically in rx callback and bail out. So
> > seems most drivers do not care about -EPROTO.
> 
> 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.

-Bin.