On Mon, Mar 14, 2022 at 12:40 AM Mario Limonciello <mario.limonciello@xxxxxxx> wrote: > > According to the Microsoft spec the _DSD `HotPlugSupportInD3` is > indicates the ability for a bridge to be able to wakeup from D3: > > This ACPI object [HotPlugSupportInD3] enables the operating system > to identify and power manage PCIe Root Ports that are capable of > handling hot plug events while in D3 state. > > This however is static information in the ACPI table at BIOS compilation > time and on some platforms it's possible to configure the firmware at boot > up such that _S0W returns "0" indicating the inability to wake up the > device from D3 as explained in the ACPI specification: > > 7.3.20 _S0W (S0 Device Wake State) > > This object evaluates to an integer that conveys to OSPM the deepest > D-state supported by this device in the S0 system sleeping state > where the device can wake itself. > > This mismatch may lead to being unable to enumerate devices behind the > hotplug bridge when a device is plugged in. To remedy these situations > that `HotPlugSupportInD3` is specified by _S0W returns 0, explicitly > check that the ACPI companion has returned _S0W greater than or equal > to 3 and the device has a GPE allowing the device to generate wakeup > signals handled by the platform in `acpi_pci_bridge_d3`. > > Windows 10 and Windows 11 both will prevent the bridge from going in D3 > when the firmware is configured this way and this changes aligns the > handling of the situation to be the same. > > Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/07_Power_and_Performance_Mgmt/device-power-management-objects.html?highlight=s0w#s0w-s0-device-wake-state > Link: https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-pcie-root-ports-supporting-hot-plug-in-d3 > Fixes: 26ad34d510a87 ("PCI / ACPI: Whitelist D3 for more PCIe hotplug ports") > Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx> > --- > drivers/pci/pci-acpi.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c > index a42dbf448860..232a8aa21bd6 100644 > --- a/drivers/pci/pci-acpi.c > +++ b/drivers/pci/pci-acpi.c > @@ -972,6 +972,29 @@ bool acpi_pci_power_manageable(struct pci_dev *dev) > return adev && acpi_device_power_manageable(adev); > } > > +/** > + * acpi_pci_s0w_supports_d3 - Deterine if ACPI device supports D3. > + * @adev: ACPI Device node. > + * > + * Validate that the GPE has been enabled for the ACPI device, and if it > + * was then evaluate the _S0W method for the ACPI device. > + * > + * Returns true when GPE is enabled and _S0W can support D3hot or D3cold. > + */ > +static bool acpi_pci_s0w_supports_d3(struct acpi_device *adev) > +{ > + unsigned long long ret; > + char *method = "_S0W"; The method var appears to be redundant. Why not use "_S0W" directly below? > + > + if (!adev->wakeup.flags.valid) > + return false; > + > + if (ACPI_FAILURE(acpi_evaluate_integer(adev->handle, method, NULL, &ret))) > + return false; > + > + return ret >= ACPI_STATE_D3_HOT; > +} > + > bool acpi_pci_bridge_d3(struct pci_dev *dev) > { > const union acpi_object *obj; > @@ -1003,6 +1026,13 @@ bool acpi_pci_bridge_d3(struct pci_dev *dev) > ACPI_TYPE_INTEGER, &obj) < 0) > return false; > I would do if (!obj->integer.value) return false; here so as to avoid evaluating _S0W if not necessary; > + /* > + * The ACPI firmware may have 'HotPlugSupportInD3' set on the device, > + * but _S0W may indicate that the device is not able to wake from D3. I'd change this comment to something like "If 'HotPlugSupportInD3' is set, but wakeup is not actually supported, the former cannot be trusted anyway, so validate it by verifying the latter." > + */ And here I would do return acpi_pci_s0w_supports_d3(adev); > + if (!acpi_pci_s0w_supports_d3(adev)) > + return false; > + > return obj->integer.value == 1; > } > > --
