Re: S4 hibernate design document [corrections]

[Fixing missing text and some odd copy/paste results.]

On Oct 16, 2025, at 09:29, Mark Millard <marklmi@yahoo.com> wrote:

> obiwac <obiwac_at_freebsd.org> wrote on
> Date: Thu, 16 Oct 2025 14:19:43 UTC :
> 
>> Hi again!
>> 
>> Following up on the previous email announcing the Foundation's intent to add S4
>> hibernate support to FreeBSD [1], kib@ has started working on a more detailed
>> design document for this:
>> 
>> https://hackmd.io/@eJNIw-SNShyq1LSp2azAcw/Bka-kXTpge
>> 
>> There are still a couple unsolved bits of the design, so we'd like to gather
>> some more feedback on this document. If you could reply with any feedback
>> within a week (before Oct 23rd) that would be ideal for us!
>> 
>> Thanks,
>> Aymeric on behalf of the FreeBSD Foundation
>> 
>> [1] https://lists.freebsd.org/archives/freebsd-current/2025-August/008616.html
> 
> I'm not sure how it fits with the material referenced above, but I'll
> note that ACPI references S4 handling in at least the following,
> including some of the _OSC usage that is tied to USB4 handling . . .
> 
> 
> 6.2.11. _OSC (Operating System Capabilities)
> 
> . . .
> 
> Since platform context is lost when the platform enters the S4 sleeping state, OSPM
> must re-evaluate _OSC upon wake from S4 to restore the previous platform state.
> This requirement will vary depending on the device specific _OSC functionality.

[I had originally noticed that what should have been "platform"
was odd by being 'pla"orm' but managed to not type the "f" in
the "tf" correction text each time.]

[The "ti" in "functionality" had been a "!".]

> . . .
> 
> 6.2.11.1.2. Evaluation Conditions

I should have quoted here:

QUOTE
The OS must evaluate _OSC under the following conditions:
END QUOTE

> . . .
> 
> Upon resume from S4. Platform firmware will handle context restoration when
> resuming from S1-S3.

[I had originally noticed that what should have been "platform"
was odd by being 'pla"orm' but managed to not type the "f" in
the "tf" correction text each time.]

[The "ti" in "restoration" had been a "!".]

> 
> . . .
> 
> 6.2.11.3. Operating System Capabilities (_OSC) for USB
> 
> . . .
> 
> Note: OSPM must re-invoke _OSC during S4 resume.
> 
> . . .
> 
> 6.3. Device Insertion, Removal, and Status Objects
> 
> . . .
> 
> For removing devices, ACPI supports both hot removal (system is in the S0 state),
> and warm removal (system is in a sleep state: S1-S4). This is done using the _EJx
> control methods. Devices that can be ejected include an _EJx control method for
> each sleeping state the device supports (a maximum of 2 _EJx objects can be listed).
> For example, hot removal devices would supply an _EJ0; warm removal devices
> would use one of _EJ1-EJ4. These control methods are used to signal the hardware
> when an eject is to occur.
> 
> The sequence of events for dynamically removing a device goes as follows:
> 
> . . .
> 


===
Mark Millard
marklmi at yahoo.com