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. Alan Stern
