Re: [RFC PATCH 0/3] ACPI, x86/cpu/amd: Parse S5_REST_STATUS from ACPI PHAT on supported AMD platforms

Hi K Prateek,

On Wed, 2026-06-03 at 06:33 +0000, K Prateek Nayak wrote:
> x86/cpu/amd bits uses the FCH register to read the S5_RESET_STATUS which
> is known to be inaccurate on some configurations where the firmware can
> consume the status before the OS boots.
> 
> Vilas and Yazen noted that the ACPI PHAT table has a read-only shadow
> copy of this state and is the preferred way for OS to consume the S5
> Reset Status.
> 
> Introduce generic helpers to parse ACPI PHAT records and use the
> platform specific helpers to interpret the vendor specific reset reason
> records.
> 
> Since these records are read-only, the status cannot be cleared once
> consumed and the last reset reason will persist across kxec until next
> reset which reintroduces the case prevented by commit e6416c2dfe23c
> ("x86/CPU/AMD: Prevent reset reasons from being retained across reboot")
> by clearing the FCH register once consumed.

It's not only about kexec.

The last reset reason register could remain unchanged when the reset is
caused by a voltage drop on a power rail, probably due to a broken power
supply or VRM. This wasted me a lot of frustrating time debugging
irrelevant reset reasons.

Eventually, I RMA'd the broken device and submitted the patch to save
other's time.

Also, some bits are not cleared by hardware as per [1]. If the firmware
doesn't clear them either they will persist anyway.

So I'd prefer clearing the register in any cases.

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=206537#attach_303991

Thanks,
Rong

> 
> This can be avoided with a boolean flags passed over as setup data
> during kexec but this scheme adds unnecessary complexity in
> implementation that has been left out for now.
> 
> Patches are based on:
> 
>   git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi
> 
> at commit 3109f9f38800 ("ACPI: button: Add missing device class clearing
> on probe failures") (tag: 'acpi-7.1-rc6')
> 
> Series has been tested on both, a Zen4 platform that does not contain
> the PHAT record, and a Zen5 platform that contains the PHAT record.
> The Zen5 platform was also tested with CONFIG_ACPI_PHAT disabled to
> confirm that logic correctly falls back to reading the FCH register.
> 
> x86 folks have been Cc'd only on the Cover letter and the x86 bits. ACPI
> folks, my fellow AMD colleagues, and the lists should have received the
> entire series. If you would like to be Cc'd on the full series for
> future posting, please let me know. Sorry in advance for any oversight!
> ---
> K Prateek Nayak (3):
>   ACPICA: actbl2.h: ACPI 6.5: PHAT: Add more struct definitions
>   ACPI: PHAT: Add generic helper to parse PHAT records
>   x86/cpu/amd: Fetch S5_RESET_STATUS from PHAT when supported
> 
>  arch/x86/kernel/cpu/amd.c |  34 ++++++++++
>  drivers/acpi/Kconfig      |  11 ++++
>  drivers/acpi/Makefile     |   1 +
>  drivers/acpi/acpi_phat.c  | 133 ++++++++++++++++++++++++++++++++++++++
>  include/acpi/actbl2.h     |  14 ++++
>  include/linux/acpi.h      |  14 ++++
>  6 files changed, 207 insertions(+)
>  create mode 100644 drivers/acpi/acpi_phat.c
> 
> 
> base-commit: 3109f9f38800841e46769e95e1ba11f1f8c7b230