Hi Greg k-h & Alan, Excuse me, both of you. I've noticed that you haven't replied to the emails for quite some time, which prompted me to send this one. I'd like to inquire if the proposal in the current email is feasible and if it can be integrated into the community. Thanks, Duan Chenghao 在 2024-10-29星期二的 16:01 +0800，duanchenghao写道： > hi greg k-h, > > 在 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? > > yes, It needs to be backported. The stable branches such as 6.6.y, > 6.10.y, and 6.11.y can be considered for the backport. > > Should we backport to these versions? > > Thanks > > Duan Chenghao > > > > > > 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 >
