RE: [PATCH] drm/xe/pm: do not warn about missing runtime PM protection after hot-unplug
"Gote, Nitin R" <[email protected]> Thu, 6 Aug 2026 06:10:21 +0000
| Newsgroups | org.freedesktop.lists.intel-xe |
|---|---|
| Message-ID | <SA3PR11MB81183F6C80A4EF8EF25E4EDDD0D22@SA3PR11MB8118.namprd11.prod.outlook.com> |
> -----Original Message----- > From: Auld, Matthew <[email protected]> > Sent: Thursday, July 30, 2026 6:05 PM > To: Gote, Nitin R <[email protected]>; [email protected] > Cc: Brost, Matthew <[email protected]> > Subject: Re: [PATCH] drm/xe/pm: do not warn about missing runtime PM > protection after hot-unplug > > On 30/07/2026 06:36, Nitin Gote wrote: > > After hot-unplug, device_del() disables runtime PM. A deferred fd > > close can still run later during process exit and destroy remaining > > exec queues, which may call xe_pm_runtime_get_noresume(). > > > > At this point pm_runtime_get_if_in_use() fails because runtime PM has > > already been disabled, so xe_pm_runtime_get_noresume() warns with > > "Missing outer runtime PM protection". This is expected after > > hot-unplug and does not indicate a missing outer runtime PM guard from the > caller. > > Is the code that calls xe_pm_runtime_get_noresume(), not trying to protect some > kind of hw access to ensure the device stays awake? I think post unplug hw > access is not allowed outside of the devm teardown sequence. Did you also > double check that where this fires, we don't then touch the hw? Yes, normally xe_pm_runtime_get_noresume() is there to protect queue teardown paths that may touch HW. I checked again; the path where this WARN fires. After hot-unplug, GuC has already been sanitized by guc_finit_hw(), So xe_uc_fw_is_running() is false and the cleanup takes the software only destroy path. No queue related hardware cleanup is reached at that point. The WARN is only because xe_pm_runtime_get_noresume() still takes a PM ref after runtime PM has already been disabled during device removal. I'll update the commit message in v3 to clarify that the queue destroy path was checked and does not touch actual hw state after unplug. Nitin