Currently, when entering s2idle, we are parsing the _S255D object to get the shallowest D-state supported by device, as acpi_stype_to_sstate() returns -1 for s2idle.
I'm not sure what exactly we should be doing in this situation, except that we should respect the D-state constraints that the SPMC gives us.
That leaves the question of what to do on devices with no SPMC but which may still support deeper hardware sleep states in s2idle.
Presumably, getting the shallowest D-state for S3 (so reading the _S3D object) is as good as we can do (though again on platforms with SPMC I suppose there is no guarantee that 1. that object exists if no S3 support 2. the reported D-state is actually deeper-or-equal to the device constraint given by the SPMC).
I think realistically just parsing _S3D is fine, until proven otherwise.
Relevant document: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/07_Power_and_Performance_Mgmt/device-power-management-objects.html#s3d-s3-device-state
Sponsored by: The FreeBSD Foundation