[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4d59c6f60fb0b1c718cd150d75471f62db03de3b.camel@kylinos.cn>
Date: Wed, 20 Nov 2024 10:14:50 +0800
From: Duan Chenghao <duanchenghao@...inos.cn>
To: Greg KH <gregkh@...uxfoundation.org>, Alan Stern
<stern@...land.harvard.edu>
Cc: stern@...land.harvard.edu, saranya.gopal@...el.com,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
linux-usb@...r.kernel.org, niko.mauno@...sala.com, pavel@....cz,
rafael@...nel.org, stanley_chang@...ltek.com, tj@...nel.org,
xiehongyu1@...inos.cn, xy521521@...il.com, kernel test robot
<lkp@...el.com>
Subject: 回复:[PATCH v4] USB: Fix the issue of
task recovery failure caused by USB status when S4 wakes up
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@...el.com
> > > > >
> > > > Closes:
> > > > https://lore.kernel.org/oe-kbuild-all/202410151722.rfjtknRz-lkp@intel.com/
> > > >
> > > > Signed-off-by: Alan Stern <
> > > > stern@...land.harvard.edu
> > > > >
> > > > Signed-off-by: Duan Chenghao <
> > > > duanchenghao@...inos.cn
> > > > >
> > >
> > > 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@rowland.harvard.edu/
> >
>
> Ah, missed that, sorry.
>
> thanks,
>
> greg k-h
Powered by blists - more mailing lists