at 21:41, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 13 Sep 2018, Kai-Heng Feng wrote:
I am working on the next version of this series, and the last missing
puzzle is to differentiate system-wide resume from runtime resume in
usb_driver's resume() and reset_resume() callback.
The parent device, rtsx_usb, has two child devices, rtsx_usb_ms and
rtsx_usb_sdmmc.
pm_request_resume() is used in rtsx_usb's resume() to facilitate USB
remote
wakeup signaling, so we don't need to poll the card slot status.
But this has a side effect: during system resume the rtsx_usb calls
pm_request_resume() in its resume(), so child devices calls their
runtime_resume() instead of resume() callback.
Have you actually observed this? It shouldn't happen.
pm_request_resume() schedules a runtime resume on the PM work queue,
but this work queue is frozen during system sleep. It doesn't unfreeze
until after all the devices have been restored to full power. Thus the
child device's resume() callback should be invoked before
runtime_resume().
You are right, I read the trace wrong.
It happens right before system-wide suspension, when the PM core resumes it
to fully functional state.
So, is it reasonable to pass pm_message_t to resume() and reset_resume()
callbacks and use PMSG_IS_AUTO() to differentiate them?
It should not be necessary to do this.
Understood, thanks.
Kai-Heng
Alan Stern
