Messages in this thread |  | | Date | Mon, 1 Dec 2025 16:40:54 -0800 | | Subject | Re: [PATCH 1/2] PM: runtime: Fix I/O hang due to race between resume and runtime disable | | From | Bart Van Assche <> |
| |
On 12/1/25 10:47 AM, Rafael J. Wysocki wrote: > Generally speaking, if blk_queue_enter() or __bio_queue_enter() may > run in parallel with device_suspend_late() for q->dev, the driver of > that device is defective, because it is responsible for preventing > this situation from happening. The most straightforward way to > achieve that is to provide a .suspend() callback for q->dev that will > runtime-resume it (and, of course, q->dev will need to be prepared for > system suspend as appropriate after that).
Isn't the suspend / hibernation order such that no block I/O is submitted while block devices transition to a lower power state? I'm surprised to read that individual drivers are responsible for preventing that blk_queue_enter() or __bio_queue_enter() run concurrently with device_suspend_late().
Regarding the UFSHCI driver: if a UFS controller is already runtime suspended, we want it to remain suspended during system suspend.
Thanks,
Bart.
|  |