[Bug 221759] New: amd_pmc: failed probe leaks LPS0 handler registration; subsequent probe hits list_add BUG in acpi_register_lps0_dev

[Bug 221759] New: amd_pmc: failed probe leaks LPS0 handler registration; subsequent probe hits list_add BUG in acpi_register_lps0_dev

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221759

            Bug ID: 221759
           Summary: amd_pmc: failed probe leaks LPS0 handler registration;
                    subsequent probe hits list_add BUG in
                    acpi_register_lps0_dev
           Product: Drivers
           Version: 2.5
          Hardware: AMD
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Platform_x86
          Assignee: drivers_platform_x86@kernel-bugs.osdl.org
          Reporter: francisdb@gmail.com
        Regression: No

Found while debugging an unrelated s2idle issue on a Framework Desktop (AMD
Ryzen AI Max 300 Series, FRANMFCP06, BIOS 03.05). Kernel: vanilla 7.1.3 (plus
an unrelated amdgpu device-link test patch; drivers/platform/x86/amd/pmc is
pristine).

if amd_pmc_probe() fails after acpi_register_lps0_dev() has succeeded (e.g.
amd_stb_s2d_init() returning -ENOMEM), the error path does not call
acpi_unregister_lps0_dev(), leaving amd_pmc_s2idle_dev_ops on the lps0 handler
list. The debugfs dir from amd_pmc_dbgfs_register() leaks the same way. After
the module is unloaded and loaded again, the next acpi_register_lps0_dev()
walks the corrupted list and hits the list_add BUG below. Even without a
reload, a failed probe leaves the LPS0 ops registered while the devm-managed
driver resources have been torn down, so the next s2idle transition would call
into stale state.

In 7.1.3 drivers/platform/x86/amd/pmc/pmc.c, amd_pmc_probe():

        if (IS_ENABLED(CONFIG_SUSPEND)) {
                err = acpi_register_lps0_dev(&amd_pmc_s2idle_dev_ops);
                ...
        }

        amd_pmc_dbgfs_register(dev);
        err = amd_stb_s2d_init(dev);
        if (err)
                goto err_pci_dev_put;      <- only does pci_dev_put(rdev)

acpi_unregister_lps0_dev() is only called in the remove path.

Reproduction (as observed; any amd_stb_s2d_init failure should do):

1. modprobe amd_pmc enable_stb=1 dump_custom_stb=1 on a long-running system.
The 16 MB S2D dump ioremap failed here (WARN at arch/x86/mm/ioremap.c:216,
devm_ioremap returned NULL), so amd_stb_s2d_init returned -ENOMEM:

   WARNING: arch/x86/mm/ioremap.c:216 at __ioremap_caller+0xfc/0x3b0
   Call Trace:
    devm_ioremap+0x5a/0xb0
    amd_stb_s2d_init+0x1c5/0x260 [amd_pmc]
    amd_pmc_probe+0x2d1/0x380 [amd_pmc]
   amd_pmc AMDI000B:00: probe with driver amd_pmc failed with error -12

2. modprobe -r amd_pmc; modprobe amd_pmc

   list_add corruption. next->prev should be prev (ffffffffb31269e0), but was
0000000000000000. (next=ffffffffc06db340).
   kernel BUG at lib/list_debug.c:29!
   Oops: invalid opcode: 0000 [#1] SMP NOPTI
   CPU: 0 UID: 0 PID: 55224 Comm: modprobe Tainted: G        W          
7.1.3-usbdep4 #4
   Hardware name: Framework Desktop (AMD Ryzen AI Max 300 Series)/FRANMFCP06,
BIOS 03.05 01/21/2026
   RIP: 0010:__list_add_valid_or_report+0x78/0xb0
   Call Trace:
    acpi_register_lps0_dev+0x44/0x80
    amd_pmc_probe+0x224/0x380 [amd_pmc]
    platform_probe+0x67/0x90
    ...

Expected fix: unwind acpi_register_lps0_dev() (and the debugfs dir / quirks) on
the amd_stb_s2d_init() failure path, or move the LPS0 registration after the
last fallible step.

Addendum: on this platform the failure is not an unlucky corner case. The SMU
firmware rejects the S2D init command outright (amd_pmc AMDI000B:00: SMU cmd
failed. err: 0xff), so amd_pmc_probe() fails with -ENOMEM on EVERY boot where
enable_stb=1 is set, silently breaking s2idle support and arming the reload
BUG. Two consequences worth considering beyond the missing unwind: (1) an
unsupported/refused S2D setup should probably not be fatal to the whole PMC
probe, and (2) the error code for an SMU refusal surfacing as -ENOMEM is
misleading.

Happy to test a patch; this machine reproduces both the probe failure (every
boot with enable_stb=1) and the reload BUG on demand.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221759] amd_pmc: failed probe leaks LPS0 handler registration; subsequent probe hits list_add BUG in acpi_register_lps0_dev

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221759

--- Comment #1 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Created attachment 310465
  --> https://bugzilla.kernel.org/attachment.cgi?id=310465&action=edit
patch series to help

Have a try with this series

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221759] amd_pmc: failed probe leaks LPS0 handler registration; subsequent probe hits list_add BUG in acpi_register_lps0_dev

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221759

--- Comment #2 from Francis DB (francisdb@gmail.com) ---
Tested the series on the reporting machine (Framework Desktop, FRANMFCP06, BIOS
03.05), applied on top of vanilla 7.1.3 (plus the unrelated amdgpu device-link
patch from bug 221073). All three patches work as intended here:

1. The reload BUG is fixed. With enable_stb=1, repeated `modprobe -r amd_pmc &&
modprobe amd_pmc enable_stb=1` cycles now complete cleanly; on the unpatched
kernel the second load was a guaranteed list_add BUG.

2. Probe now survives the STB failure: "amd_pmc AMDI000B:00: STB initialization
failed (-12), continuing without STB support", and /sys/kernel/debug/amd_pmc/
stays available.

3. s2idle is fully functional afterwards: an rtcwake s2idle cycle right after a
failed STB init reached full hardware residency (S0ix residency 59.08 s of a 60
s sleep per s0ix_stats), confirming the msg_port restore; previously the failed
init would have left msg_port on MSG_PORT_S2D.

One residual issue in amd_stb_s2d_init(), now visible thanks to the error
propagation fix: on this platform S2D_TELEMETRY_SIZE now succeeds, but a later
S2D command is refused ("SMU cmd failed. err: 0xff") and the
S2D_PHYS_ADDR_LOW/HIGH results are never checked, so stb_phys_addr ends up 0
and devm_ioremap(0, 16 MB) trips the ioremap-on-RAM WARN before failing with
-ENOMEM:

  amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff
  ------------[ cut here ]------------
  ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff
  WARNING: arch/x86/mm/ioremap.c:216 at __ioremap_caller+0xfc/0x3b0, CPU#13:
modprobe/4592
  Call Trace:
   devm_ioremap+0x5a/0xb0
   amd_stb_s2d_init+0x239/0x280 [amd_pmc]
   amd_pmc_probe+0x2d1/0x370 [amd_pmc]
  ...
  amd_pmc AMDI000B:00: STB initialization failed (-12), continuing without STB
support

The end result is still correct (STB unavailable, driver fine), but checking
the return codes of the two phys-addr commands (or rejecting a zero address)
would turn this into a clean bail-out instead of a WARN backtrace that taints
the kernel.

Thanks for the quick turnaround. For the series as posted:

Tested-by: Francis De Brabandere <francisdb@gmail.com>

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221759] amd_pmc: failed probe leaks LPS0 handler registration; subsequent probe hits list_add BUG in acpi_register_lps0_dev

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221759

Mario Limonciello (AMD) (mario.limonciello@amd.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|drivers_platform_x86@kernel |mario.limonciello@amd.com
                   |-bugs.osdl.org              |

--- Comment #3 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Sent for review.

https://lore.kernel.org/platform-driver-x86/20260717162023.956346-1-mario.limonciello@amd.com/

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.