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: 26+ 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-25 3:59 ` [PATCH 03/13] platform/apple-gmux: Fix MMIO interface Atharva Tiwari
2026-10-25 4:27 ` sashiko-bot
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 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-25 3:59 ` [PATCH 11/13] drm/amd/display: Refuse DP AUX " Atharva Tiwari
2026-10-25 4:41 ` sashiko-bot
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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox