Hi Greg KH/Alan, I haven't received a reply from both of you for a long time. Sorry for the disturbance. May I ask if the current patch can be merged into the mainline or stable branch? I need this conclusion as it is very important to me. Thank you very much. Thanks Duan Chenghao 在 2024-10-29星期二的 04:27 +0100，Greg KH写道： > On Thu, Oct 24, 2024 at 04:46:48PM +0800, duanchenghao wrote: > > hi greg k-h, > > > > 在 2024-10-24星期四的 09:05 +0200，Greg KH写道： > > > On Thu, Oct 24, 2024 at 10:40:38AM +0800, Duan Chenghao wrote: > > > > When a device is inserted into the USB port and an S4 wakeup is > > > > initiated, > > > > after the USB-hub initialization is completed, it will > > > > automatically enter > > > > suspend mode. Upon detecting a device on the USB port, it will > > > > proceed with > > > > resume and set the hcd to the HCD_FLAG_WAKEUP_PENDING state. > > > > During > > > > the S4 > > > > wakeup process, peripherals are put into suspend mode, followed > > > > by > > > > task > > > > recovery. However, upon detecting that the hcd is in the > > > > HCD_FLAG_WAKEUP_PENDING state, it will return an EBUSY status, > > > > causing the > > > > S4 suspend to fail and subsequent task recovery to not proceed. > > > > - > > > > [ 27.594598][ 1] PM: pci_pm_freeze(): > > > > hcd_pci_suspend+0x0/0x28 > > > > returns -16 > > > > [ 27.594601][ 1] PM: dpm_run_callback(): > > > > pci_pm_freeze+0x0/0x100 > > > > returns -16 > > > > [ 27.603420][ 1] ehci-pci 0000:00:04.1: > > > > pci_pm_freeze+0x0/0x100 > > > > returned 0 after 3 usecs > > > > [ 27.612233][ 1] ehci-pci 0000:00:05.1: > > > > pci_pm_freeze+0x0/0x100 > > > > returned -16 after 17223 usecs > > > > [ 27.810067][ 1] PM: Device 0000:00:05.1 failed to quiesce > > > > async: error -16 > > > > [ 27.816988][ 1] PM: quiesce of devices aborted after > > > > 1833.282 > > > > msecs > > > > [ 27.823302][ 1] PM: start quiesce of devices aborted after > > > > 1839.975 msecs > > > > ...... > > > > [ 31.303172][ 1] PM: recover of devices complete after > > > > 3473.039 > > > > msecs > > > > [ 31.309818][ 1] PM: Failed to load hibernation image, > > > > recovering. > > > > [ 31.348188][ 1] PM: Basic memory bitmaps freed > > > > [ 31.352686][ 1] OOM killer enabled. > > > > [ 31.356232][ 1] Restarting tasks ... done. > > > > [ 31.360609][ 1] PM: resume from hibernation failed (0) > > > > [ 31.365800][ 1] PM: Hibernation image not present or could > > > > not > > > > be loaded. > > > > > > > > The "do_wakeup" is determined based on whether the controller's > > > > power/wakeup attribute is set. The current issue necessitates > > > > considering > > > > the type of suspend that is occurring. If the suspend type is > > > > either > > > > PM_EVENT_FREEZE or PM_EVENT_QUIESCE, then "do_wakeup" should be > > > > set > > > > to > > > > false. > > > > > > > > Reported-by: kernel test robot < > > > > lkp@xxxxxxxxx > > > > > > > > > Closes: > > > > https://lore.kernel.org/oe-kbuild-all/202410151722.rfjtknRz-lkp@xxxxxxxxx/ > > > > > > > > Signed-off-by: Alan Stern < > > > > stern@xxxxxxxxxxxxxxxxxxx > > > > > > > > > Signed-off-by: Duan Chenghao < > > > > duanchenghao@xxxxxxxxxx > > > > > > > > > > > What commit id does this fix? > > > > The current patch is not intended to fix an issue with a specific > > commit, but rather to address a long-standing problem in the USB > > core. > > So should it be backported to older stable kernels? If so, how far > back? > > > > And I missed where Alan provided a signed-off-by, where was that? > > > > In the following email, Alan proposed using "Signed-off-by" for > > signing. > > https://lore.kernel.org/all/489805e7-c19c-4b57-9cd7-713e075261cd@xxxxxxxxxxxxxxxxxxx/ > > > > Ah, missed that, sorry. > > thanks, > > greg k-h
