Re: [PATCH] USB:Fix ehci infinite suspend-resume loop issue in zhaoxin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022/4/6 00:02, Alan Stern wrote:
On Wed, Mar 16, 2022 at 10:18:39AM +0800, WeitaoWang-oc@xxxxxxxxxxx wrote:
On 2022/3/15 11:18, Alan Stern wrote:
On Tue, Mar 15, 2022 at 08:39:09PM +0800, WeitaoWang-oc@xxxxxxxxxxx wrote:
I have encountered the following situation if EHCI runtime suspend is
enabled by default.

Some things about this still confuse me...

1.Wake from system to disk and boot OS.

You're talking about resuming after hibernation, right?

You're right.
2.EHCI will entry runtime suspend after enumerated by driver during boot
phase of suspend to disk

I'm not sure what you mean by "boot phase of suspend to disk".  This is
while the restore kernel is starting up at the beginning of resume from
hibernation, right?

You understood exactly what I was saying.

Okay, so we're waking up from hibernation.

3.EHCI will be placed to freeze state and ehci_resume is called after image
is loaded.

ehci_resume is called to leave runtime suspend.  Going into the freeze
state doesn't require any changes.

In fact, the resume kernel doesn't call ehci_resume at all.  Here's what
it does:

	The resume kernel boots;

	If your patch causes STS_PCD to be set at this point, the flag
	should get cleared shortly afterward by ehci_irq;

	ehci-hcd goes into runtime suspend;

	The kernel reads the system image that was stored earlier when
	hibernation began;

	After the image is loaded, the system goes into the freeze
	state (this does not call any routines in ehci-hcd);
On this phase, pci_pm_freeze will be called for pci device. In this
function, pm_runtime_resume will be called to resume already
runtime-suspend devices. which will cause ehci_resume to be called.
Thus STS_PCD flag will be set in ehci_resume function.

Thanks
Weitao Wang

	The resume kernel transfers control to the image kernel;

Now the image kernel is running.  It goes into the restore state, which
involves calling ehci_resume.  Presumably your patch cases the STS_PCD
flag to get set at this point.
o
But that's all!  The system is now back up, out of hibernation, and
running normally.  There are no more calls to check_root_hub_suspended

4.If PCD flag is set(caused by patch), then HCD_FLAG_RH_RUNNING will be set.

5.Pci_pm_freeze_noirq is called to check ehci root hub state and return
value is -EBUSY. which will cause
   quiesce phase of suspend to disk fail.

You're talking about check_root_hub_suspended() in hcd-pci.c, right?

It's right.

So how can this happen, given that the image kernel doesn't call
pci_pm_freeze_noirq?

Alan Stern
.



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux