From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 741F6BA3D for ; Sat, 8 Aug 2026 15:08:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786201732; cv=none; b=PKh/wyYIy+KjlsgaSewL0Rhk1SpbBnUKXYz7cBGz0iHQZda2V/+ilxMg3ASedioLdzlDrJF+23Kwafdf1FVGT5s7wXT/nH0jdowhFR+poID42uv76S6r5mhj4X7U5G0umHJ/tE8GEV3Y1HvM03EeOGa0fNC5mar5nBMIQpbYyfs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786201732; c=relaxed/simple; bh=B///jw+Sio/CEZUlXYcAgc4i5QJz1XbwZfwYvidho5M=; h=Message-ID:Date:To:Cc:MIME-Version:Content-Type:From:Subject; b=ua+bRF2Zz7dfFXnvWUcYZm2lGgrsfp+bhwn8N7VcL8oWiiVHhgqxhVoI9CnW2R/Ka2gKmRL1gWVq3YWhlYx3kdu4uOf69nNWL+TX3Hc6bYwzozxjlogZ0IXHo5z1a8rWPGb40M3FJBtycUU0pwFZJmhEaipXgf11obk08xxEaqI= 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=P+JLkQGQ; arc=none smtp.client-ip=209.85.214.179 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="P+JLkQGQ" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2ced3386430so6397025ad.1 for ; Sat, 08 Aug 2026 08:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786201731; x=1786806531; darn=vger.kernel.org; h=subject:from:content-transfer-encoding:content-type:mime-version:cc :to:date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=xrJoFcJRcNN7a4wuSEk0P7pO/7NYaaMRF1MmKxQ8zlc=; b=P+JLkQGQr4uuxspxmF+T2aP6d9oHVIoZ1iHd3QAZLjCYgT3ZY/DvaZ4mJRpGZJTjtw Ai0DP6fXGcrQmS9ic0l4I7tkLmlPtSKZe+7s3AdAe1rH5OsIUeYi7N9AdRDUL2IbIhNr UnvE9jYmHlMLJSSEUos0WWk83DKdxxx2nPvFHmRO+wznb6ea3g0FhevO7eOBdy90xZdk wK41RqhbHL4SwgQWXr202uduuV5gIP/0wFXFnB4DKE90D7DhxJLjEOipKZDXyCGJmwKE D3ak1JBKzsjb84QJat/ipLVB/S9t2UBPAGkAgxjAvrUR87qXQqQ6lW0Q1V4JLqyGj9U3 zBOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786201731; x=1786806531; h=subject:from:content-transfer-encoding:content-type:mime-version:cc :to:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=xrJoFcJRcNN7a4wuSEk0P7pO/7NYaaMRF1MmKxQ8zlc=; b=YZADYg7KAwau/rMaDM/Mq5Q5degWSoQ65rCzVgYRaRVixrmbryupAQngdJzYfyg/fm FURFMdmaJfpyAWQOY5GDJ1S/+mJ9q5dMtyKAVLpSKV2yg/QIttDQXGaa+3aST28ngdKT +ADzK3JTRnssXnB31vfpUe4drJ7GhhghZuiz7AEbeiln5+NFUuMKcQksljRYW4GrW/c+ EH9Gxz8+2ry00ofLmeJkpgXvFehH9Wl6GxFplwWR9tDYYmE453/zvwostIa6PAh8CBFi mbEwaevjixIKRG9yajDor0AKsIxNLR6+UqIUF3F2CuzIiUlRCgCZZTTjwG0Z02B9S8Eq ywsA== X-Forwarded-Encrypted: i=1; AHgh+Rr+uJS9c81j2U2BjKtK5q0GJMQo61Y1qHJg4qdCd9FCCdj1u3R02UEATkI8d66AkOKTat/3K5SWf337EoU=@vger.kernel.org X-Gm-Message-State: AOJu0YyuTcbeN139vfXq58YuwPVRpbBckPcJrv7sZ80u3gziU00UZBBZ 8EoaMD7Khs/gxaCQE7xFu2lHfz2NcO2UuzeItRQpnL8NjC72h6BivysCkUUkZgio X-Gm-Gg: AR+sD12t5UP8xljmXA8AvaGw2Hy4svpWCb4eBnTELPHYCSX6mnvBOjuI171UrKzBr1V srt8Q3DKizOxe7VTEL8TOKlxZq2dDIkQbIiBAYlqZiZcpq4xDgk5vZ+xskCa4MOIyGsrCU3Wc7V nVqa0KajoXqBb5JLOkq6wL2Vze+6nLqFc4Q8LCP57NjEZdVCrll8ElnC4Zi1fGi7WvuuFPfTAwv ps+FjG9h89oNw6o5gJc+7RbXbQ7LFivXlQFXGzjlCQkgeofINWnr09aIj8HCgbJQSk/40m/VMUK zOwvSzRZh3/FZ8ZTB/9GZ5NDvWC3nPIZltuyDGPrZCyD3Pf7W73Dj9M5wiOpEi0Jk9cqJkrB0j4 +7hw6CaM7Kko919/IKBZnFdXB9sOdo+V9COuXSNIrYBb8ThuLBUBecNQVvYR+y3gQaRpd/3QKNE 0Ofc/8LupIhLFpv28fxuyBXwCDxBYV8UHOJzLEgkOJGFbVEkTndXhlo/oxYPsmxTWI5HjiEP3S7 P9AiQf2JCWEisthyKA4V4u+z73gL3g= X-Received: by 2002:a17:903:f90:b0:2c9:b2c1:13ec with SMTP id d9443c01a7336-2d294c225a1mr145556715ad.11.1786201730777; Sat, 08 Aug 2026 08:08:50 -0700 (PDT) Received: from hws_send.eml (114-47-78-137.dynamic-ip.hinet.net. [114.47.78.137]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d14dbeaad6sm19213225ad.51.2026.08.08.08.08.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Aug 2026 08:08:50 -0700 (PDT) Message-ID: <20260808230846.12232.alvinhuang0603@gmail.com> Date: Sat, 08 Aug 2026 23:08:46 +0800 To: Ben Hoff , Mauro Carvalho Chehab Cc: Hans Verkuil , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org 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=UTF-8 Content-Transfer-Encoding: 8bit From: Hao-Qun Huang Subject: [PATCH] media: hws: Wait for IRQ handler before returning buffers hws_stop_streaming() disables capture and then collects the active and queued buffers straight away. Clearing cap_active and setting stop_requested only stops a VDONE handler that has not checked them yet; one already running on another CPU has passed those checks and cannot be recalled. That handler snapshots v->active into a local pointer and drops irq_lock before it touches the buffer, so stop_streaming can run in between. Without a next_prepared buffer both paths complete the same buffer, and the second vb2_buffer_done() hits the WARN_ON for a buffer that is no longer active. With a next_prepared buffer the snapshot is the only remaining reference to the old active buffer, so stop_streaming returns without it and vb2 reports "stop_streaming operation is leaving buffer %u in active state" before completing it with an error. Either way the driver breaks the vb2 rule that stop_streaming has to give back every buffer it owns before it returns. Wait for the handler once the hardware is disabled and before the buffers are collected. The live mode change and the channel cleanup paths already do this around the same collect helper. Fixes: ba07fd2f5742 ("media: pci: add AVMatrix HWS capture driver") Assisted-by: Claude:claude-opus-5 Signed-off-by: Hao-Qun Huang --- Found by code inspection; I do not have an HWS card, so this is not reproduced on hardware. What convinced me is the asymmetry inside the driver itself: the live mode change path calls synchronize_irq() before the same hws_video_collect_done_locked() helper, and hws_stop_streaming() does not. drivers/media/pci/hws/hws_video.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/pci/hws/hws_video.c b/drivers/media/pci/hws/hws_video.c index 18e4bc6901d3..7f7e51040926 100644 --- a/drivers/media/pci/hws/hws_video.c +++ b/drivers/media/pci/hws/hws_video.c @@ -1292,6 +1292,8 @@ static void hws_stop_streaming(struct vb2_queue *q) WRITE_ONCE(v->stop_requested, true); hws_enable_video_capture(v->parent, v->channel_index, false); + if (hws->irq >= 0) + synchronize_irq(hws->irq); /* 2) Collect in-flight + queued under the IRQ lock */ spin_lock_irqsave(&v->irq_lock, flags); -- 2.43.0