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

[Henry Lin]

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.

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. With usb_set_interface(..., 0), the host and device sequence states
match again and repeated stop/start cycles complete successfully.

The affected devices we have seen include:

  - ID 8086:0b07 Intel Corp. RealSense D435
  - ID 2560:c1d0 e-con Systems See3CAM_CU130
  - ID 2b03:f582 STEREOLABS ZED camera

I understand that the earlier discussion raised two important concerns:

  1. Whether this should be fixed in uvcvideo or lower in the USB/xHCI stack,
     since CLEAR_FEATURE(ENDPOINT_HALT) should normally reset the endpoint
     halt condition and data toggle/sequence state.

  2. Whether calling usb_set_interface(..., 0) for single-altsetting bulk UVC
     devices could regress existing devices.

For the first point, my understanding is that the kernel helper
usb_set_interface(..., 0) issues SET_INTERFACE and lets the USB core
reinitialize the endpoints for the selected alternate setting, including their
data toggle/sequence state. The traces suggest that, in this stop/start path,
CLEAR_FEATURE(ENDPOINT_HALT) alone is not enough to make the host and device
restart the next bulk stream from the same sequence state. The additional
usb_set_interface(..., 0) call makes repeated stop/start cycles reliable on
the affected hardware.

For the second point, I can provide before/after test results from the
affected hardware listed above. I can also test a quirk-based version if that
would be preferred over changing the generic bulk-stream stop path.

I would appreciate guidance on whether this one-patch RFC is the preferred
direction, or whether upstream would prefer a UVC quirk-based change for the
affected devices listed above.

Thanks,
Henry