From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D35E360EED for ; Mon, 25 May 2026 23:55:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779753324; cv=none; b=i3UCfVERBnNsT6dgoN9LECUBmy/J3gSAwuhTo4l02x/ujZVm4YZY0h6pnxDAabygvQ0EOPJ+ulQH+m6b9Rboo6a3ycikQqVKZB6Iz5GYRpULtd/oBZDbsFYFbZtstWy88S4vLhr3oFEn1UF11TH709XSpsP3UyjQ593a7Oh/fqQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779753324; c=relaxed/simple; bh=el6r8DT5ghDym332JOmydWiAPWQT30GdHB99sVXRFJQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=t3LPsulKmpAJzDYjuXb/LsLcXbQjPjXMxfEKtEy0qEOSReWKGTDoZLqQkPyX44ZBF8OSiscnqI3n8jRB47g5fHK74GniHLtuSwkykbQzPKqbx60TpTdiGLQfPZ/3lqnLvV3TXSSJarezGHC5UVpdEtc6Z05ELzaYkkFMYwjrg9c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ayngoZjg; arc=none smtp.client-ip=209.85.167.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ayngoZjg" Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-5a88db610ccso10059746e87.2 for ; Mon, 25 May 2026 16:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779753321; x=1780358121; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Q7XVCwdYYkBXbgnl1CqkyAGE7Fe+DjxICS1PudZs9wE=; b=ayngoZjgC5tCSnR7XMAmGtVvHUdb82bIV6BHaWyoMio7K46kyKikSt5LZfCOPuiCde os2zYxntoae2tC4ubAqxPtOQdBEfk6Z4SE0ySg4sQqnBp0Fvxdwi+a6cAaMe2tuStKpI 7kBowCWZMC88gT5vvRKIKs5MesG6+CoKh+BEJbhVHhe/n8x+LCPYZlhwP56xoLmO8Ag7 LCEuOl+BainJPJ8+mjYJ/uP8TJFCoGC5oC+oOOtEmtrQGpc77UXX54V0pRfKEcZSdsdz Qxixn5yXOyHb1z2Q/zgLij+4vClZK1LBSS/Ol5+eHA0DVPm984Eb71dgcuXhj28REp4f R0Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779753321; x=1780358121; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Q7XVCwdYYkBXbgnl1CqkyAGE7Fe+DjxICS1PudZs9wE=; b=mL5ZULz3+KHJdzshS1U04w54+XfmWVvPVFDK+FAakNNfux9v9haPWtISaO12H9s3+F DAzM38MyoYidU+hiKEZ0gMtIncsFmmHyU62zqB93RsjiFHNEQmWfIHKwmq0DvUgEiTSk f+pZ7XTbhQZ8bHb4h12UU1i9I55fuzFzZ2ghs4PH7etzISN8e4QOUlhNHhEUS5JNSPH3 Xl6mM4nLmvjjL2BE+46vvkdLDSdX8LVB30jpA0j5Eh5uy6SmnrjKRsxGBMT1R4TOl1iW Eb1ggukzdp61Mszah4hV66iQcAI0FEaNaWCk1k6kVynFket4KV45/6t1B/KRnmdrs2Cb Pl4w== X-Forwarded-Encrypted: i=1; AFNElJ9Q7qLBohi+X4Mu2i/XkZArGfCH5dybxjT2LMmWO+GidJCvRMkjyOWBNgQCnlsuVJcnsDglEtxEPo7ObLQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyorgMA6IFHm2Mwka4TEHHjmLtZ/QcRNZIP1Xg81ia1Liwl16t0 tOKMnBlNOquwPZ9qSTJz1/yhCZWA3SbpVa/JGgaK3tApoSoLi1eA6M2w X-Gm-Gg: Acq92OGFM6DQiFynbC58BS9ckNN+uWF+QRXy29EiZXxNKAWuPLNDTgKxB/JAspqSX+d WXf8tkqgwOGuqARhp58kMhA7Z3YzAWeOG78yDmiukvM+HBXoAmtGiM8fqY2YQUKnVnaRXFEdN5Y +PpwlKwF9XVhdD8B+qy90RfsQ9Ys/RWwYL77oKB2THLp/zZvHavpz+Oox5sF8jsfUT9N3WIHLfw pzbR4Y9TPFqC/qwlo08KWks90S40pj1LWcOMA10CRCgHbn5qM/ro4ZAHPmwW3WWyoNnaGNKVzsK amnld+E6xT0t3cWuR2g9ob245x93v6hHOWkwKCSkwZ4lFHZq7iSUXFHg8n9Yg6dU7bGar11CwDr uCtQgP5sEs/CHb9sfO3KCwMWezZO7sjRfnO23A4Ul75xusiVtSdShsCuF8kn0EsQb9PNdJp9JvZ YKs6MVDnuuH63C1jIcDuRRpNiioROChoRM X-Received: by 2002:ac2:41c1:0:b0:5a8:8de0:4576 with SMTP id 2adb3069b0e04-5aa323a9cc5mr3991315e87.25.1779753320567; Mon, 25 May 2026 16:55:20 -0700 (PDT) Received: from foxbook (bfk48.neoplus.adsl.tpnet.pl. [83.28.48.48]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5aa462cf5f7sm47404e87.12.2026.05.25.16.55.18 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 25 May 2026 16:55:19 -0700 (PDT) Date: Tue, 26 May 2026 01:55:14 +0200 From: Michal Pecio To: Henry Lin Cc: Laurent Pinchart , "Mauro Carvalho Chehab" , , , Subject: Re: [RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop Message-ID: <20260526015514.466b72d4.michal.pecio@gmail.com> In-Reply-To: <20260525182028.2148267-1-henryl@nvidia.com> References: <20260525182028.2148267-1-henryl@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 25 May 2026 18:20:27 +0000, Henry Lin wrote: > 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. You are referring to uvc_video_stop_streaming() here, right? This calls usb_clear_halt(), which is supposed to reset both ends of the pipe. > 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. I suppose you mean SuperSpeed and xHCI, so that's a little mysterious because xhci_hcd resets host sequence state on Transaction Error completions and hence it should recover from such mismatch after the first error. Of course, no mismatch should exist in the first place. But xhci_hcd was broken for years and failed to clear host sequence state when requested by usb_clear_halt() in some cases. This recent commit fixed the most blatant bug and was motivated precisely by this UVC issue, which I encountered myself. 25e531b422dc usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable() Please check if this works for you, it's included in 7.1 RCs and some latest stable kernels. If not, you might be affected by other bugs. > 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 think all bulk devices were affected, and all SuperSpeed bulk devices were affected particularly badly. Regards, Michal