Re: [RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop

[Alan Stern]

On Mon, May 25, 2026 at 06:20:27PM +0000, Henry Lin wrote:
> Hi,
> 
> I would like to revive an old UVC bulk-streaming issue originally reported
> by Hans Yang. I am sending this RFC on his behalf for discussion before
> submitting a non-RFC patch.
> 
> Hans previously proposed making uvcvideo call usb_set_interface(..., 0)
> when stopping a bulk-based stream, before clearing halt on the bulk endpoint.
> The issue was discussed here:
> 
>   https://www.spinics.net/lists/linux-usb/msg171584.html
> 
> The current upstream stop path calls usb_set_interface(..., 0) only when the
> streaming interface has more than one alternate setting. For single-altsetting
> bulk devices, uvcvideo only sends CLEAR_FEATURE(ENDPOINT_HALT) to the bulk
> endpoint.

How does it send this request?  By calling usb_clear_halt()?  Or some 
other way?

> The patch in this RFC changes uvc_video_stop_streaming() to always call
> usb_set_interface(..., 0) to reset the streaming interface first. For
> bulk devices, the existing CLEAR_FEATURE(ENDPOINT_HALT) request is still
> sent afterwards.
> 
> On the affected devices, current upstream stop/start sequence can leave
> the next bulk stream failing immediately with transfer errors such as:
> 
>   uvcvideo: Non-zero status (-71) in video completion handler.
> 
> USB bus traces show that, without usb_set_interface(..., 0), the host
> continues the next bulk stream with the previous stream's sequence state,
> while the device expects the new stream to start from the initial sequence
> state.

(I assume by "sequence state" you mean the USB-3 sequence number 
associated with the endpoint.)

Are you certain about this?  The usb_clear_halt() routine has reset 
the endpoint state, including the sequence number, ever since commit 
3444b26afa14 ("USB: add reset endpoint operations") was added in 2009.

If uvcvideo isn't using usb_clear_halt(), the simplest solution might be 
to make it do so.

Alan Stern