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 A80321A3160 for ; Thu, 30 Apr 2026 02:15:31 +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=1777515334; cv=none; b=BahxJVuQ7wshNdN/TqyFcKlX5hXd0NLOluy9Vt/XDC+QyueeyOa78pmlALpbNSXYXw3yffLlkbjSpuZOrbULUVXEqi9u4sppt17jewAg3Tc8aBNju3EPcz29ashf/r+dQlTXKIX27v1jkhOOawuI39oPWv08YgSp17VWERCtRnE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777515334; c=relaxed/simple; bh=1zCC7AKObbyieR95/cFJ9+NHzXUtcyrsCGYZkWH+vHc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=K0wUP/nPbg7GelL99cVKgUkSxZGFWwev7uw5+92rEZO1X3jhODfANqWc0ydkCgwx7VXfwGSA27I0bS0raIF1KgD8FkROL+PtaYHKztXM7CmiNdDNcSh4Uct9IyxDs1RU1P/39EW5jI49iwoL5uDv42hXo2ks9YPuHWGjVg+MPbs= 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=mpn0GLPc; 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="mpn0GLPc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniontech.com; s=onoh2408; t=1777515291; bh=HW+NJazsSNoz1Jtg9xGELfevFxqLCMTYFWcOjXN5PKY=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=mpn0GLPc4wTqWLZF8NsTE8SvUARTMKi6awhMZ2wN5o8sglN8iSCAA/SOKT4gT3VTm pgAbSu7FvtSOLzPd6wa+Utrcao6xQ4odBsMRYxQSMg/0FfFy364CXDeCDy0Hndx268 PeenzvjJsemCLtsTKgp7W9Lhi/ITyYqZ6kVIFVrA= X-QQ-mid: zesmtpip4t1777515277t274f69a4 X-QQ-Originating-IP: VddoJS8umxccj0SlXDjXRRJDPuzqz5Aeq5L4hpRgcm8= Received: from localhost.localdomain ( [localhost]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 30 Apr 2026 10:14:34 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 1 X-BIZMAIL-ID: 2437857808746587561 EX-QQ-RecipientCnt: 14 From: Haowen Tu To: stern@rowland.harvard.edu Cc: oneukum@suse.com, gregkh@linuxfoundation.org, rafael@kernel.org, linux-usb@vger.kernel.org, linux-pm@vger.kernel.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com, hansg@kernel.org, mchehab@kernel.org, pavel@kernel.org, lenb@kernel.org, kernel@uniontech.com Subject: Re: [RFC] USB/PM: should USB interface drivers distinguish hibernation THAW from RESTORE? Date: Thu, 30 Apr 2026 10:14:33 +0800 Message-Id: <20260430021433.2083281-1-tuhaowen@uniontech.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <37c9bf07-7b21-403c-b4fe-d54ff6f811db@rowland.harvard.edu> References: <37c9bf07-7b21-403c-b4fe-d54ff6f811db@rowland.harvard.edu> 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: zesmtpip:uniontech.com:qybglogicsvrsz:qybglogicsvrsz3b-0 X-QQ-XMAILINFO: NC8a1JKFOHmWaYvTdXt5biM7gP5naZzOA9Jlw7rPCWnJ9NETrkA67tof +k6ZLcPejAKu89n2GwYYfCTB+JkFCLAXUwhYAfc1fQsjQtrgMNk9WrIhu4exCDSmEQSWav3 Gnk4Jqalcox35RQqufLHxTRyLLs50uMT/sOy5ecmt+UzzLFcmNfJSKYLpBkYQ1vNBbvIRQy RhiqVVfn3FVlcGj32s7tekGYzouVSwtnEzRf+vxpgCD5PWJmbv3rGn8+AbZhXW9Yt1oZo0Q DgrIN8PgBuHrGbC9oPke56I73U2zov0OmPLVGrc8K3wFZTJJSFV5TQCKELvgkZ38ChDuNAx 65M0b3H7a/edY6MhTWpCBo3TmQlY3qBZdH+9Q3OPe+aHqlyhUFKtMSkXW5IMOqBKlkQAZzu 4SrDx4NbdH0OpWSDWhQsQGcvOUSwszfYEQuLAYHS0idDenuPF19bCZ37WI8BPWfGFKnG4xn Vhn9Vg4thAKwWf+60VaiBxODVnbN473ozCd3qhMG7j3ebx3nWJI+6qT/mqr7Goq8cdRaNKJ DiFyIjE+IQ8L2JEJ9ix+iEEW36we1MEKSfoP5nJ0uD0Uq7qsSEjPNoV54SUv3UD2f6qVtgc H7YREUp/ZRgBDOCfy087UPbVoYbooT/Xm0uIUbj7S0lB2/K0V2fiMB7fhyDi2cLp1v7K6UY EsB/E0zMwqXlJ7QX/UMwf8/oFWtdFN97Zb1jWpkLzOfqtWMhZSvNPw+E9UVsT6UEGzibOUy mWAvB2+eU36Yy3R3JnNwKa8KzbFhrTzTBqpeGgS/VIZRliYDCAHDkBXNg5Pu83psFRN3a2Y wvsyz90fYLRNjJuQYcArmNrWpOJaPC/ZSFdopB21GKUT9pXmqLg3u1gYl4EEqpviVJ8IckF ZEqhmP1wL0dW0OUlTDpuaHW1z5lkbR1Z0c7+trshctS25/wJ9rPboi7vimhZ4BJRfmEJDBd eP3SQ6vZ25lzHnjSA/H9pS7T8nVJcELMJ0EMrq7/uCb7fiEMHy2Yoyp5ISLx6lzXyPw4= X-QQ-XMRINFO: M/715EihBoGS47X28/vv4NpnfpeBLnr4Qg== X-QQ-RECHKSPAM: 0 Hi Oliver, Alan, Thanks for the feedback. I think my original RFC title and framing were too narrow. What originally triggered this discussion was a UVC camera: during the THAW phase used for hibernation image writeout, the camera's streaming resume path runs again and can turn the indicator LED back on. From that observation, I started by looking at the USB side. But after your replies, I agree that this is not really a USB-specific problem. The more fundamental question seems to be whether, in the current S4 flow, resuming the full device set at that point is the intended model, or whether there is any room for resuming only the subset of devices needed for image writeout and whatever else must remain functional during that phase. So the real issue I wanted to ask about is closer to this: during hibernation image writeout, should PM resume all previously frozen devices, or is there any room for a more minimal resume of only the devices required for writeout and their dependencies? If writeout succeeds, the system will power off afterward, which made me wonder whether every previously frozen device must be resumed at that stage in the same way it would be for ordinary recovery. If not, avoiding unnecessary resume work in that phase might also reduce the time spent before final poweroff, although I do not have measurements for that. On the other hand, if writeout fails, the system needs to continue running, so the remaining devices would still have to be recovered correctly. I agree that this failure path makes the problem much more subtle than I described in the RFC. I also agree with Oliver's point that this cannot be expressed as "storage devices only". In practice, any such approach would need to account for dependencies and for other classes of devices that may still matter during the writeout phase. So at this point I am no longer trying to argue for a USB-specific interface change. Instead, I am trying to understand whether this is a valid PM/hibernate design question at all, namely whether the writeout phase should conceptually be treated as: 1. a full THAW of the suspended system, as it is today, or 2. potentially a narrower resume of only the devices needed for writeout, followed by broader recovery only if writeout fails. I do not have a concrete implementation in mind yet, and I am not sure whether such an approach would even fit well with the current PM core model. I first wanted to check whether this is considered a valid problem to discuss. If the answer is that the current full-THAW behavior is simply the intended model, that is also useful for me. In that case, I should not treat the UVC behavior as evidence of a missing USB-side mechanism. Thanks, Haowen