On Thu, May 06, 2021 at 05:44:55PM +0000, Guido Kiener wrote: > > -----Original Message----- > > From: Alan Stern > > Sent: Thursday, May 6, 2021 3:49 PM > > To: Kiener Guido 14DS1 <Guido.Kiener@xxxxxxxxxxxxxxxxx> > > > > > > Thanks for your assessment. I agree with the general feeling. I > > > counted about hundred specific usb drivers, so wouldn't it be better to fix the > > problem in some of the host drivers (e.g. urb.c)? > > > We could return an error when calling usb_submit_urb() on an erroneous pipe. > > > I cannot estimate the side effects and we need to check all drivers > > > again how they deal with the error situation. Maybe there are some special driver > > that need a specialized error handling. > > > In this case these drivers could reset the (new?) error flag to allow > > > calling usb_submit_urb() again without error. This could work, isn't it? > > > > That is feasible, although it would be an awkward approach. As you said, the side > > effects aren't clear. But it might work. > > Otherwise I see only the other approach to change hundred drivers and add the > cases EPROTO, EILSEQ and ETIME in each callback handler. The usbtmc driver > already respects the EILSEQ and ETIME, and only EPROTO is missing. > The rest should be more a management task. > BTW do you assume it is only a problem for INT pipes or is it also a problem > for isochronous and bulk transfers? All of them. Control too. > > Will you be able to test patches? > > I only can test the USBTMC function in some different PCs. I do not have automated > regression tests for USB drivers or Linux kernels. > Maybe there is company who could do that. Well then, if I do find time to write a patch, I'll ask you to try it out with the usbtmc driver. Alan Stern
