Re: [PATCH 1/5] misc: rtsx_usb: Use USB remote wakeup signaling for card insertion detection

[Kai-Heng Feng]

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