On Tue, Mar 31, 2020 at 10:46 PM Jean-Baptiste Maneyrol <JManeyrol@xxxxxxxxxxxxxx> wrote: > by reading kernel documentation, I was thinking that PM was excluding this possibility. > > Quote from power/runtime_pm: > "The PM core does its best to reduce the probability of race conditions between the runtime PM and system suspend/resume (and hibernation) callbacks by carrying out the following operations: > * During system suspend pm_runtime_get_noresume() is called for every device right before executing the subsystem-level .prepare() callback for it and pm_runtime_barrier() is called for every device right before executing the subsystem-level .suspend() callback for it. In addition to that the PM core calls __pm_runtime_disable() with ‘false’ as the second argument for every device right before executing the subsystem-level .suspend_late() callback for it. > * During system resume pm_runtime_enable() and pm_runtime_put() are called for every device right after executing the subsystem-level .resume_early() callback and right after executing the subsystem-level .complete() callback for it, respectively" > > The 2 suspend callbacks are also locking the device mutex. > > But I can totally misunderstood the situation. If you can confirm if it is the case or not, that would be really helpful. I have re-read the thread where I remember traces from. So, it was rather IRQ handler context. So, in here probably everything is okay. -- With Best Regards, Andy Shevchenko
