Hi, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Wed, 3 Aug 2016, Felipe Balbi wrote: > >> >> --- a/drivers/usb/dwc3/core.c >> >> +++ b/drivers/usb/dwc3/core.c >> >> @@ -1192,6 +1192,7 @@ static int dwc3_runtime_resume(struct device *dev) >> >> } >> >> >> >> pm_runtime_mark_last_busy(dev); >> >> + pm_runtime_put(dev); >> >> >> >> return 0; >> >> } >> > >> > This may be correct, but it certainly looks odd. For example, it >> > wouldn't work right if you ever called pm_runtime_resume() instead of >> > pm_runtime_get(). >> >> well, we don't. But is there an alternative for this? > > What are you trying to accomplish? Is the problem that wakeup signals > only cause the platform device to be runtime-resumed, but you also need > the HCD to wake up? And conversely, whenever the HCD gets > runtime-suspended you also want the platform device to go into runtime > suspend? this is DWC3 as peripheral-only. PCI Wakeup (PME) wakes up dwc3-pci, but we need dwc3 core (a platform device) to be resumed as well. > If that's so, the proper solution is for the platform device's > runtime_resume routine to call pm_runtime_resume() for the HCD, and > never to do pm_runtime_get_* or pm_runtime_put_* on the platform > device. The HCD's callback routines would then be responsible for > doing runtime-PM gets and puts on the HCD as required. hmm, interesting approach. Should probably work with my setup as well. I'll test that out tomorrow :-) Thanks for the hint. In any case, I suppose this would be material for v4.9 while $subject is -rc material, agree? -- balbi
Attachment:
signature.asc
Description: PGP signature
