Page MenuHomeFreeBSD

call AcpiLeaveSleepStatePrep after re-enabling interrupts
ClosedPublic

Authored by avg on May 5 2018, 5:58 AM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 23 2023, 12:05 AM
Unknown Object (File)
Jun 15 2023, 6:57 PM
Unknown Object (File)
Jun 3 2023, 1:47 AM
Unknown Object (File)
May 17 2023, 6:28 PM
Unknown Object (File)
Mar 21 2023, 9:35 PM
Unknown Object (File)
Mar 21 2023, 9:30 PM
Unknown Object (File)
Mar 17 2023, 3:01 PM
Unknown Object (File)
Dec 23 2022, 3:19 AM
Subscribers

Details

Reviewers
jkim
avg
Summary

I want to do this change because this call (actually,
AcpiHwLegacyWakePrep) does a memory allocation and ACPI namespace
evalution. Although it is not very likely to run into any trouble, it
is still not safe to make those calls with interrupts disabled. Also,
AcpiLeaveSleepStatePrep is documented as called when interrupts are
enabled. witness(4) and malloc(9) do not currently check for a context
with interrupts disabled via intr_disable and we lack a facility for
doing that. So, those unsafe operations fly under the radar. But if
intr_disable in acpi_EnterSleepState was replaced with spinlock_enter
(which it probably should be), then witness and malloc would
immmediately complain.

The ACPI wakeup sequence is very sensitive to changes, but I consider
this change to be rather safe. What AcpiHwLegacyWakePrep essentially
does is writing a value corresponding to S0 into SLP_TYPx bits of PM1
Control Register(s). According to ACPI specifications that write should
be a NOP as SLP_EN bit is not set. Additionally, there are no accesses
to ACPI hardware and firmware between the old location of the call and
the new one. So, the move should not affect the interaction between
then OS and ACPI platform.

Test Plan

No regressions on my test system, but it's a desktop.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 16442
Build 16361: arc lint + arc unit