Re: [PATCH] r8152: stop submitting rx for -EPROTO

[Alan Stern <stern@rowland.harvard.edu>]

On Thu, Sep 30, 2021 at 11:30:17AM +0200, Oliver Neukum wrote:
> 
> On 29.09.21 11:52, Jason-ch Chen wrote:
> > On Wed, 2021-09-29 at 08:14 +0000, Hayes Wang wrote:
> >>
> > Hi Hayes,
> >
> > Sometimes Rx submits rapidly and the USB kernel driver of opensource
> > cannot receive any disconnect event due to CPU heavy loading, which
> > finally causes a system crash.
> > Do you have any suggestions to modify the r8152 driver to prevent this
> > situation happened?
> >
> > Regards,
> > Jason
> >
> Hi,
> 
> Hayes proposed a solution. Basically you solve this the way HID or WDM do it
> delaying resubmission. This makes me wonder whether this problem is specific
> to any driver. If it is not, as I would argue, do we have a deficiency
> in our API?
> 
> Should we have something like: usb_submit_delayed_urb() ?

There has been some discussion about this in the past.

In general, -EPROTO is almost always a non-recoverable error.  In 
usually occurs when a USB cable has been unplugged, before the 
upstream hub has notified the kernel about the unplug event.  It also 
can occur when the device's firmware has crashed.

I do tend to think there is a deficiency in our API, and that it 
should be fixed by making the core logically disable an endpoint 
(clear the ep->enabled flag) whenever an URB for that endpoint 
completes with -EPROTO, -EILSEQ, or -ETIME status.  (In retrospect, 
using three distinct status codes for these errors was a mistake.)  
Then we wouldn't have to go through this piecemeal approach, 
modifying individual drivers to make them give up whenever they get 
one of these errors.

But then we'd have also have to make sure drivers have a way to 
logically re-enable endpoints, for the unlikely case that the error 
can be recovered from.  Certainly set-config, set-interface, and 
clear-halt should do this.  Anything else?

Alan Stern