From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpbgsg2.qq.com (smtpbgsg2.qq.com [54.254.200.128]) (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 A13CF356768 for ; Tue, 2 Jun 2026 03:25:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.254.200.128 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780370722; cv=none; b=LqCJmCy62x2O1k6e47kdBdsFBo2xCCD1k9H6R3CG3tYZIfrDWfD0YQKS1LEAAVBRFRH//A1K2wzXIIpLJSzRQzD/HWuShoWOD+hT+ZCp+g+RfSroawtfgV7ZIghlT5YpswpsDRc64MKFpWeg4ifRpgtdFVxtfoKI8V5PtCqC728= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780370722; c=relaxed/simple; bh=rcfAdu5JFRv9+PpxSEcJbPJNa2MF5dRJrCA4ua5wwCM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=eZEyp2O31SbzG6gEVSTyQ7+v3AZl8ZPSqKSWC5x5HjfxrX4LpZK9g6FBKsk0SvOr3IcGEncGm6hBUIU/WbusSkG8BgAVGQ+WJ+zfiQN43yhS6coPqFw8xN1+3/SkTrOLBoY0fvm6jumpim5ZMGOi1AGwkQbaptiQCl0oBdLtx9c= 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=jhMV4kcy; arc=none smtp.client-ip=54.254.200.128 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="jhMV4kcy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniontech.com; s=onoh2408; t=1780370682; bh=dn8IPubHvNeXEKuaSdvnWy3G1wDEcbOyhaRuCaFScCU=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=jhMV4kcyTwzd7Lz9VsxXwVHc1X5GMvtVGcgyYyHu/DzwvPdnRkbslcpCmPg6Ze50w 13Qy+eis/sCZrxJm9Wbl0h3LyfvpD/Osqj3Mv629rOeb8l3Aty9vrCSTXDQQ51kjkW Z0P74pGoGPTGxEYcLVsq+peyfZWZYU7OxhaMruUs= X-QQ-mid: zesmtpsz3t1780370660t3a9299aa X-QQ-Originating-IP: fmcuOrwsv3WsdBsngma3ziQrLiGuL1e1TVsH2hItIlk= Received: from localhost.localdomain ( [113.57.152.160]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 02 Jun 2026 11:24:17 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 1 X-BIZMAIL-ID: 18384957555402254008 EX-QQ-RecipientCnt: 15 From: Haowen Tu To: rafael@kernel.org Cc: gregkh@linuxfoundation.org, hansg@kernel.org, kernel@uniontech.com, laurent.pinchart@ideasonboard.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, stern@rowland.harvard.edu, tuhaowen@uniontech.com Subject: Re: [PATCH v2 1/2] PM: hibernate: add pm_hibernation_snapshot_done() helper Date: Tue, 2 Jun 2026 11:24:13 +0800 Message-Id: <20260602032413.1540166-1-tuhaowen@uniontech.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: References: <20260528081840.3528089-2-tuhaowen@uniontech.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: zesmtpsz:uniontech.com:qybglogicsvrsz:qybglogicsvrsz3b-0 X-QQ-XMAILINFO: NBbJe76T/DL9p77p5+pJCbM2jIRH0jIDY7Ok45+tChVy9dNSqhda+VE1 6wZYP6aGEQohv4lFKfEivNwJONjtoPW+g1Rtqgwtxlb4g2T3Arbf6zVvQfJ28x8Qh485kiv hVhrA3ER6rLwBRi88XJ1uN79NPjPzeXhx9o5eaNl6ZVLLB7l6Q1oEeuGLt1QM3ylwbeMLwe +LjH+VemvLVfqO/Uw4RwYJtOlao+HbtEnKGaV3SgCbI71kYs502650FZY6Dhc/1AL0tWwgF aE3HCVn6KnR60hDlnxmeNHydk13xqe6YSFPTfS7EBaANeESX1nG4AKL/cRqojsGkOp9TCRH d7vr3slwt5CW3o0QXHQ6yuc9E+xsgyrjXQ3riv6HTDHgZnTPOFFQHcz34HILvTPrD6BsdDY Uh9uHfuflwlAPSqQzJc6jFWgL6XHGaKWwgF0xBDmFph0jlSQxhG0QXHJ5xGB3fPOIq6QqG7 iBIWeobjZE/Wj8MTNov5+OBHlV81fcca0qQfMhlvKzimoJmIRKZdTMaHGdiN2keUxY6bceP 6YPtIC4aEiN48h8WgNBkg/VB6o73MylI+Oa7ZaLKhB9Lx5hLTeX5wsYmcwJGd0ZLUKMXh+S wGLZCawkCautl2O7G8OK9ntW7iq2jBOWD5+tJ0ibPpxgJSUqQoHEeLrCKjE0ldJVfjE1/nk LzLGzsDAhTBrcjOzAgi9TeKlMEcZwb8aM8oJX4D0aOpl4BVJ+F1Py9dFvAeWqeVoTsvi5qY wQgzrTD7FrLXczow3O0S3RNdzDyrNXb7VuyrKQ7jigIDK2XLlnnbgc3jxNgUHYAJlIfdYtz PeNt/dlnyW0R3KHgwezHn68t5S2wJcvpdd1aaAlKziUn6ubQl8g0ieREXCXe53p6L+VoQKL BsMNobSwIn5UmpeLKf/UxE0YGHgAtrUQsy1kcPCeP6qmlOMXhSjU1yR0QEx5YHRTO86MRhe cD452vfWn8teGJ7zZJUZfISDk94nwyBDpCVexsiEUZ1XzUJBaRdlmm8w2dHnOQTNa9YzY+I P8pw1y1rLmOd4JxO+nSK1SiSUfM6qFzTPzN52KJQ== X-QQ-XMRINFO: MSVp+SPm3vtSI1QTLgDHQqIV1w2oNKDqfg== X-QQ-RECHKSPAM: 0 Hi Rafael, On Mon, Jun 01, 2026 at 08:22:00PM +0200, Rafael J. Wysocki wrote: > On Thu, May 28, 2026 at 10:19 AM Haowen Tu wrote: > > > > During hibernation, after create_image() saves the memory snapshot, the > > kernel resumes devices with PMSG_THAW solely to write the hibernation > > image to storage, then powers off. Drivers for hardware not involved in > > storage I/O have no reason to reinitialize during this transient phase. > > They do have a reason for doing it. > > Their poweroff (or shutdown) callbacks will be called while preparing > to power off the system subsequently and they need to be ready for > that. The most straightforward way to achieve this is to resume so > they can "suspend" again. Thanks for pointing this out. My understanding is that the hibernation image contains the state from the snapshot point, that is before the subsequent THAW and image-write phase. Therefore, on the later restore path, the kernel resumes from the state captured at the snapshot point and still goes through the normal PMSG_RESTORE resume path. The THAW activity after the snapshot is not part of the restored image state. That said, I agree that some devices may need to be resumed before the final poweroff/shutdown callbacks run, so the wording in the changelog is too broad. I did not mean to suggest that all non-storage devices can or should skip THAW resume. The helper is meant to expose this PM state, not to prescribe that drivers should skip THAW resume. Whether a driver uses it would remain a driver-specific decision, based on whether skipping the hardware reinitialization is safe for that device, including its subsequent poweroff/shutdown handling. Drivers that need the normal THAW resume before poweroff/shutdown would simply not use it. In this series the user is uvcvideo. For USB devices, and specifically for UVC cameras, the device is hotpluggable and the driver already needs to tolerate device removal and disconnect-like conditions. The UVC driver also does not need the camera streaming engine to be restarted in order to write the hibernation image, while restarting it has a visible side effect by turning the camera LED back on. The check is placed after the driver's frozen state is cleared, so if image writeout fails, the driver is not left in the frozen state. I will reword the changelog in the next version to avoid implying that non-storage devices generally have no reason to resume during THAW. > > Clear in_suspend before releasing snapshot memory on hibernation failure > > paths and after swsusp_write() returns, so the helper does not report a > > stale snapshot after the snapshot pages have been released. > > This last piece needs to be split off into a separate patch. Sure, I will split the in_suspend cleanup into a separate patch in the next version. I will wait for your feedback before sending the next version. Thanks, Haowen