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

[bugzilla-daemon@kernel.org]

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.