From: sashiko-bot@kernel.org
To: "Atharva Tiwari" <atharvatiwarilinuxdev@gmail.com>
Cc: "open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
"open list:DRM DRIVERS" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 12/13] drm/amdgpu: Skip AC/DC notification while the GPU is runtime suspended
Date: Sun, 25 Oct 2026 04:43:39 +0000 [thread overview]
Message-ID: <sashiko-outbox-184076@kernel.org> (raw)
In-Reply-To: <20261025040046.1602-13-atharvatiwarilinuxdev@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] drm/amdgpu: runtime PM reference leak in amdgpu_pm_acpi_event_handler()
- [High] drm/amdgpu: negative return treated as active in amdgpu_pm_acpi_event_handler()
- [Medium] drm/amdgpu: missed SMU AC/DC update in amdgpu_pm_acpi_event_handler() during resume
--
commit 5f8266206967cf1a10c12c800fc318910f1e455a
Author: Andre Eikmeyer <dev@deq.rocks>
drm/amdgpu: Skip AC/DC notification while the GPU is runtime suspended
This commit updates amdgpu_pm_acpi_event_handler() to check if a GMUX GPU is
runtime active via pm_runtime_get_if_active() before sending AC/DC power
source notifications to the SMU. When the GPU is suspended, it records the
updated power state in adev->pm.ac_power so it can be applied upon resume.
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> index 808be6c425bff..b64f0b681fe1a 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
[ ... ]
> @@ -498,20 +499,26 @@ int amdgpu_dpm_smu_i2c_bus_access(struct amdgpu_device *adev,
>
> void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev)
> {
> + int active = 0;
> +
> if (adev->pm.dpm_enabled) {
> mutex_lock(&adev->pm.mutex);
> + active = adev->pm.rpm_mode == AMDGPU_RUNPM_GMUX ?
> + pm_runtime_get_if_active(adev->dev) : 1;
[Severity: Medium]
Can an AC/DC notification be missed if an ACPI event races with runtime
resume?
During rpm_resume() -> amdgpu_pmops_runtime_resume() ->
amdgpu_device_resume(), dev->power.runtime_status remains RPM_RESUMING until
amdgpu_pmops_runtime_resume() returns.
Inside amdgpu_device_resume(), adev->pm.ac_power is consumed without holding
adev->pm.mutex during amdgpu_device_ip_resume() -> pp_resume() ->
hwmgr_resume() on PowerPlay GPUs and during amdgpu_device_ip_late_init() ->
smu_late_init() on swsmu GPUs:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:amdgpu_device_resume() {
...
r = amdgpu_device_ip_resume(adev);
...
r = amdgpu_device_ip_late_init(adev);
if (r)
goto exit;
queue_delayed_work(system_dfl_wq, &adev->delayed_init_work,
msecs_to_jiffies(AMDGPU_RESUME_MS));
exit:
...
/* Make sure IB tests flushed */
flush_delayed_work(&adev->delayed_init_work);
}
If amdgpu_pm_acpi_event_handler() runs after IP resume/late_init has already
applied the power state, while flush_delayed_work() or the remainder of
amdgpu_pmops_runtime_resume() is still executing, pm_runtime_get_if_active()
sees runtime_status == RPM_RESUMING and returns 0. Would that cause the
handler to skip notifying the SMU after the resume path has already passed
the point where adev->pm.ac_power is applied, leaving the GPU with stale
AC/DC limits?
> +
> if (power_supply_is_system_supplied() > 0)
> adev->pm.ac_power = true;
> else
> adev->pm.ac_power = false;
>
> - if (adev->powerplay.pp_funcs &&
> - adev->powerplay.pp_funcs->notify_ac_dc)
> - amdgpu_dpm_notify_ac_dc(adev);
> -
> - if (is_support_sw_smu(adev))
> - smu_set_ac_dc(adev->powerplay.pp_handle, true);
> + if (active) {
[Severity: High]
Should this check be (active > 0) instead of (active)?
pm_runtime_get_if_active() returns 1 when the device is active, 0 when it is
not active, and -EINVAL without incrementing dev->power.usage_count when
runtime PM is disabled (dev->power.disable_depth > 0 or !CONFIG_PM).
On GMUX systems, amdgpu_pci_probe() sets DPM_FLAG_SMART_PREPARE |
DPM_FLAG_SMART_SUSPEND | DPM_FLAG_MAY_SKIP_RESUME, which allows a
runtime-suspended GMUX GPU (powered off, with adev->pm.dpm_enabled still true
on PowerPlay GPUs) to remain suspended across system sleep while the PM core
increments dev->power.disable_depth during __device_suspend_late() through
dpm_resume_early().
If an ACPI AC/DC event runs while disable_depth > 0, active will be -EINVAL
and if (active) will evaluate to true, calling amdgpu_dpm_notify_ac_dc() or
smu_set_ac_dc() without a runtime PM reference while the GPU may be powered
off.
> + if (adev->powerplay.pp_funcs &&
> + adev->powerplay.pp_funcs->notify_ac_dc)
> + amdgpu_dpm_notify_ac_dc(adev);
>
> + if (is_support_sw_smu(adev))
> + smu_set_ac_dc(adev->powerplay.pp_handle, true);
> + }
[Severity: High]
Does amdgpu_pm_acpi_event_handler() leak the runtime PM usage reference on
adev->dev when the GPU is active?
When adev->pm.rpm_mode == AMDGPU_RUNPM_GMUX and the GPU is in the RPM_ACTIVE
state, pm_runtime_get_if_active(adev->dev) increments dev->power.usage_count
and returns 1. Because there is no matching pm_runtime_put_autosuspend() or
pm_runtime_put() call after notifying the SMU, won't each ACPI AC/DC event
while the GPU is active permanently leak a runtime PM reference and prevent
the GPU from runtime suspending again?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261025040046.1602-1-atharvatiwarilinuxdev@gmail.com?part=12
next prev parent reply other threads:[~2026-10-25 4:43 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-25 3:59 [PATCH 00/13] Fixes for apple-gmux and runtime support Atharva Tiwari
2026-10-25 3:59 ` [PATCH 01/13] platform/apple-gmux: Fix power for MMIO systems Atharva Tiwari
2026-10-25 4:49 ` sashiko-bot
2026-10-25 3:59 ` [PATCH 02/13] PCI: Disable pcie port and access on D3 on specific amd devices Atharva Tiwari
2026-10-25 4:34 ` sashiko-bot
2026-10-27 23:00 ` Bjorn Helgaas
2026-10-28 0:08 ` Atharva Tiwari
2026-10-28 1:19 ` Atharva Tiwari
2026-10-25 3:59 ` [PATCH 03/13] platform/apple-gmux: Fix MMIO interface Atharva Tiwari
2026-10-25 4:27 ` sashiko-bot
2026-10-25 22:10 ` kernel test robot
2026-10-25 3:59 ` [PATCH 04/13] platform/apple-gmux: Fix Interrupts for MMIO systems Atharva Tiwari
2026-10-25 4:39 ` sashiko-bot
2026-10-25 3:59 ` [PATCH 05/13] platform/apple-gmux: Write switch state to EFI on MMIO devices Atharva Tiwari
2026-10-25 4:36 ` sashiko-bot
2026-10-25 3:59 ` [PATCH 06/13] platform/apple-gmux: Add parameter to configure boot gpu Atharva Tiwari
2026-10-25 4:33 ` sashiko-bot
2026-10-25 3:59 ` [PATCH 07/13] platform/apple-gmux: Add check to detect FSS Atharva Tiwari
2026-10-25 4:30 ` sashiko-bot
2026-10-25 3:59 ` [PATCH 08/13] platform/apple-gmux: Add documentation about iMacs Atharva Tiwari
2026-10-25 4:37 ` sashiko-bot
2026-10-25 3:59 ` [PATCH 09/13] drm/amdgpu: Add Apple GMUX runtime PM support Atharva Tiwari
2026-10-25 5:56 ` sashiko-bot
2026-10-25 3:59 ` [PATCH 10/13] drm/amdgpu: Catch register access while GMUX keeps the GPU off Atharva Tiwari
2026-10-25 4:40 ` sashiko-bot
2026-10-26 18:25 ` Alex Deucher
2026-10-27 8:29 ` Atharva Tiwari
2026-10-27 15:22 ` Alex Deucher
2026-10-25 3:59 ` [PATCH 11/13] drm/amd/display: Refuse DP AUX " Atharva Tiwari
2026-10-25 4:41 ` sashiko-bot
2026-10-26 18:25 ` Alex Deucher
2026-10-25 3:59 ` [PATCH 12/13] drm/amdgpu: Skip AC/DC notification while the GPU is runtime suspended Atharva Tiwari
2026-10-25 4:43 ` sashiko-bot [this message]
2026-10-26 18:18 ` Alex Deucher
2026-10-25 3:59 ` [PATCH 13/13] drm/amd/display: Skip panel power savings on eDP links without a panel Atharva Tiwari
2026-10-25 4:30 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-184076@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=atharvatiwarilinuxdev@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.