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.
