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.

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
-- 
2.34.1

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

Hello Rong,

On 6/3/2026 8:07 PM, Rong Zhang wrote:
>> 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 a ton for the additional context. I'm checking with the BIOS
folks if this PHAT record behaves any differently or if it just mirrors
the FCH::PM::S5_RESET_STATUS at the time the firmware loads.

If it is the latter, yes, I agree with you that we need to clear the
FCH register regardless. I'll adjust the v2 accordingly based on what
the BIOS folks come back with.

-- 
Thanks and Regards,
Prateek