Re: [PATCH] media: imon: make send_packet() more robust

[Sean Young <sean@mess.org>]

On Tue, Jul 15, 2025 at 09:30:02PM -0400, Alan Stern wrote:
> On Tue, Jul 15, 2025 at 09:19:18PM +0100, Sean Young wrote:
> > Hi Alan,
> > 
> > On Sun, Jul 13, 2025 at 11:21:24AM -0400, Alan Stern wrote:
> > > On Sun, Jul 13, 2025 at 04:11:47PM +0800, Hillf Danton wrote:
> > > > [loop Alan in]
> > > 
> > > I assume you're interested in the question of when to avoid resubmitting 
> > > URBs.
> 
> > > In theory it's okay to resubmit _if_ the driver has a robust 
> > > error-recovery scheme (such as giving up after some fixed limit on the 
> > > number of errors or after some fixed time has elapsed, perhaps with a 
> > > time delay to prevent a flood of errors).  Most drivers don't bother to 
> > > do this; they simply give up right away.  This makes them more 
> > > vulnerable to short-term noise interference during USB transfers, but in 
> > > reality such interference is quite rare.  There's nothing really wrong 
> > > with giving up right away.
> > > 
> > > As to which error codes drivers should pay attention to...  In most 
> > > cases they only look at -EPROTO.  According to 
> > > Documentation/driver-api/usb/error-codes.rst, -EILSEQ and -ETIME are 
> > > also possible errors when a device has been unplugged, so it wouldn't 
> > > hurt to check for them too.  But most host controller drivers don't 
> > > bother to issue them; -EPROTO is by far the most common error code 
> > > following an unplug.
> > 
> > Thank you for explaining that, very helpful. Would it be useful to have
> > this in the USB completion handler documentation?
> 
> I don't know what USB completion handler documentation you're talking 
> about.  Is it something in the Documentation/ directory?  If it is then 
> it should already include or refer to error-codes.rst.

I can't see anything in error-codes.rst or URB.rst about the possibility
of retrying after -EPROTO errors or how the callback should respond if
it wants to give up. USB drivers seem to do all manner of different things.

> > I think that is why this driver code is so awkward.
> 
> That's what usb_driver_claim_interface() is for.  IIRC, the cdc-acm 
> driver uses it in exactly this way.

Very interesting, we should look at re-writing this driver. Note this
function is not documented in Documentation/driver-api/usb/

Thank you for your help

Sean