From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpbguseast2.qq.com (smtpbguseast2.qq.com [54.204.34.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 293E1B67E for ; Fri, 31 Jul 2026 01:31:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.204.34.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785461501; cv=none; b=I5dULs0Tz8Ko48ExEpwAHVf3Na7Ysn+o64H4nAjuvd8bgHZLXMNp231Mwg6txvxtkqmbmhoWGZFiZuhe3r44AM4nB+tdMjx0MY4gTR+GsS5PTCTS1nnjocWd4b+YfsytSuH6s3WagmALakbnsmUlWe6u5z4cVzcAJHdwjDMg48c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785461501; c=relaxed/simple; bh=JZl7+Iq+TkZ6KtfzXP/ZMoFzLUUZIidJ3IyemrpboMg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=lfki6figZl3CW4yn67BYGWIhQX66tMxIN3VVgSWwiogltVh+UWulk3ppTlWzX9RzC0qzep+rRRlVnHZXSkyu2BoHscKaqmKv530anfgy4MNwYiaHPazwJCErF0Hngf9VCyb5AOR6qfIV+CR45gjNiik7pPwMwMdAHuc6s0AXf3o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=uniontech.com; spf=pass smtp.mailfrom=uniontech.com; dkim=pass (1024-bit key) header.d=uniontech.com header.i=@uniontech.com header.b=H92FSBaW; arc=none smtp.client-ip=54.204.34.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=uniontech.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=uniontech.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=uniontech.com header.i=@uniontech.com header.b="H92FSBaW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniontech.com; s=onoh2408; t=1785461453; bh=VOddwZB2ExC+qB3w6kRHEoXg3vMe6ErDqJixfcX5e1U=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=H92FSBaWrKRawfxCMbomsQbj8WsPt3A51NINu3iqjU1TkHLV/c/CbC81OGWm35RHX n/b6HdG4XNT6PH4sWW7jkRLlEbNdH7iAjw+eMJhycEelxtzcuSelBDFRlX64plc1th XaLV0DAw/HdIZZDrsS8fxQ/wTetGbgNONJRAvj7I= X-QQ-mid: esmtpgz15t1785461428tf7c0f590 X-QQ-Originating-IP: PGexwB07BwrBrwYbQb7cSisCsll351s8YVPydnYQXxs= Received: from localhost.localdomain ( [113.57.152.160]) by bizesmtp.qq.com (ESMTP) with id ; Fri, 31 Jul 2026 09:30:26 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 1 X-BIZMAIL-ID: 10344273564525670133 EX-QQ-RecipientCnt: 15 From: Haowen Tu To: laurent.pinchart@ideasonboard.com, stern@rowland.harvard.edu, rafael@kernel.org Cc: tuhaowen@uniontech.com, gregkh@linuxfoundation.org, hansg@kernel.org, kernel@uniontech.com, lenb@kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, mchehab@kernel.org, oneukum@suse.com, pavel@kernel.org Subject: Re: [PATCH v4 4/4] media: uvcvideo: defer streaming restart after hibernation snapshot Date: Fri, 31 Jul 2026 09:30:24 +0800 Message-Id: <20260731013024.1577337-1-tuhaowen@uniontech.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20260730153817.GA1555869@killaraus.ideasonboard.com> References: <20260730153817.GA1555869@killaraus.ideasonboard.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: esmtpgz:uniontech.com:qybglogicsvrsz:qybglogicsvrsz3b-0 X-QQ-XMAILINFO: MNbA5mkmBXEJFVyegfpyKWO2vPfTTr0fqV+wE5W74Z96RDKDF+mesuIG SKiReYV5F67ZYLCOrmtPBs+XMHGRQY7byoWgeRI3VW+woYWtMBriRUMB23mefgZINm3gfVB PclGY42x+Cf3N56MQUPuwC3W5lAA1gVZqWJAexa8eC9p+4/wcT+nXdZDnOljTuXIgohj3bp wyBW9XaL5WNSptiG4NIwa5+aHD1umFuuOVKELx18gDpYG2oSIZSB5C7ty/raHuWNqDBmcJp FhBcs50M2/uXIiKRjUZS/IypJrfieJxNKJL9w5hyBK16F4doAcwHOBW+YWrFgfZ4Hh+iGbS jOJ5vYZgFIfYaoBFftPFVMIxjbMFk/KjVNTrDUajKSrpaisWGjp683cIkwizf1tYaEOms2C ltSlLa8O43s33Cr05iw6vf52ji4ndcJW6KK3CbaLIKPvLILWMVg20L6spzbik8FkpUNn+JV TInjpRApO8mOQBA7/l+bxY5MyEDQaFDvXhjG3q/kOVGVXgOZW+zXSLqjvFAdFT2ixEMfrtw ymDc2pERHOBDuit1LL37FVBOfAxVZJIcDKDOEt4q9EtpdCJCT6iEUsx9pHXwARseQqbaB9p DIMdPr4HZ5CQXOM8B9Gldv75b3jBkQPBk5aYEpPC61bVSg+B87sCXDZbas9jW1iBd3tKCon H/MY/ZmMxrL9BIRknxi95BCJ2iEILpmqs0hc02lvGXHr41w/1yG4dAEqwMUj88ENJTnot/C J6fSGnwamCWtl3KYYnYfoejkJS5VT0rtjDjCC4GNiLwx+mxBmJA707peATsOUlMP4D6D8Ub s10E34wLdVZzrLevhakm+68SWJ57jLIuw9MS75C6wMy3Jz5ursKvoaS7Lh6ElxcekyBLBTg 5198aLH+zNIyBdMNzmvnVCcaAu142MR8NZOF2WQ+TeDhW3Hk3OVZmNve8VDWCVg7eWfna1e s595awvQvisJsMuOwGnhVdsM2rHffu7qo+V75FYyx67m//jDwrjCrl+1Q3huaAAiZ9pEHWM zm5F16GgSYGa5cN4jj4h31NER+isSRjAHx52RjVg== X-QQ-XMRINFO: Nq+8W0+stu50tPAe92KXseR0ZZmBTk3gLg== X-QQ-RECHKSPAM: 0 Hi Laurent, Alan, On Thu, Jul 30, 2026 at 06:38:17PM +0300, Laurent Pinchart wrote: > Something like that. I'm very biased as I mostly work on multimedia > devices, but it feels to me that for many drivers the current > hibernation procedure is too complex. Those drivers don't need to > differentiate suspend and hibernation, they only need to be instructed > to suspend at some point, and resume later. Resuming could occur when > the system is woken up, or when hibernation fails in the THAW phase, and > those drivers wouldn't care to differentiate between the two. Seeing an > extra resume + suspend cycle due to the hibernation machinery needing to > write the image to disk, and having to handle that cycle manually as in > this series, is additional complexity that (unless I'm missing > something) could be handled by the PM core. I agree. This was actually close to what I considered before trying the smaller UVC-specific approach. My initial thought was that the PM core could distinguish the post-snapshot resume used for writing the hibernation image from the later path where the original kernel continues running. In that model, devices that do not need to be resumed during the image-write phase could be marked accordingly. They would remain suspended after FREEZE, and would only be resumed if the original kernel continues running instead of powering down. That would avoid making each driver open-code the same kind of post-snapshot THAW check and recovery handling. It would also avoid the notifier ordering issue in v4, because the PM core would keep the normal device ordering when resuming the skipped devices. The reason I did not start with that approach is that it looked like a larger PM core change. It needs a clear definition of which devices need to be resumed for hibernation image writeout, and it needs to preserve parent-device and storage-stack dependencies. It also needs to handle the case Alan mentioned, where the restore kernel cannot restore the image and sends THAW before continuing; that path should not be skipped in the same way as the post-snapshot image-writeout resume. So v4 was an attempt to keep the change local to the observed UVC issue while still handling the swsusp_write() failure path. But I agree that, if this is viewed as a more general PM problem, a PM-core solution with an explicit skip and recovery mechanism would be cleaner than a UVC notifier. Rafael, would such a PM-core direction be acceptable to explore? For example, a device flag indicating that the device does not need to be resumed during the post-snapshot image-write phase, with PM resuming those skipped devices if the original kernel continues running, before userspace is thawed? If that direction is preferred, I can rework the series around a PM-core-managed mechanism. Thanks, Haowen