[PATCH] ACPI: PCI: take native PME control on Apple machines

[PATCH] ACPI: PCI: take native PME control on Apple machines

[Francisco Beltrán Millalén]

Since commit 7bc5a2bad0b8 ("ACPI: Support _OSI("Darwin") correctly")
negotiate_os_control() skips the _OSC handshake on Apple machines and
hardcodes the set of features the OS takes over, because those firmwares
return failure once _OSI("Darwin") has been acknowledged.  The hardcoded
set is ~OSC_PCI_EXPRESS_PME_CONTROL, i.e. everything except PME.  No
reason was given for leaving PME out.

The result is that host_bridge->native_pme stays 0, so portdrv never
registers the PME service for any root port.  A PCIe device that
runtime suspends still arms PME# (the PCI core enables it because
pci_dev_run_wake() only looks at capability), asserts it when it needs
attention, and is never resumed: no service handles the root port
interrupt, and the polling fallback in pci_pme_list_scan() skips the
device whenever the bridge above it is runtime suspended, which is
exactly when the device itself is suspended.

On a MacBookPro14,3 this silently breaks USB-C hotplug.  Both xHCI
controllers sit inside the Thunderbolt (Alpine Ridge) switches and
runtime suspend to D3hot when idle, together with their parent
bridges.  Plugging a SuperSpeed device in is then never noticed:

  0000:7d:00.0 suspended, PMCSR 0x8103 (D3hot, PME_En=1, PME_Status=1)
  ... no kernel message at all, for minutes ...

The device only appears once something else resumes the controller,
which makes it look intermittent.  The firmware on this machine does not
handle PME on behalf of the OS either: XHC2/XHC3 declare _PRW returning
GPE 0x6D, that GPE is enabled and has never fired, and its _L6D handler
notifies PWRB, XHC1 and HDEF only - never XHC2 or XHC3.

With PME control taken, the root port PME interrupt is serviced and the
controller is resumed as soon as something is plugged in.

Use calculate_control() for the assumed set rather than open coding it:
that is by definition the set that would have been requested, it drops a
magic constant, and on a kernel built without some of those features it
no longer claims control of services the OS cannot provide.

Note this also makes pme_is_native() true for pciehp (drivers/pci/
hotplug/pciehp_core.c), so hotplug ports now disable their interrupt
across suspend and clear spurious events on resume, as they do on every
non-Apple machine.  x86_apple_machine covers Macs back to 2006, so this
reaches models that were never tested with native PME.

Tested on a MacBookPro14,3, 6.18.49, with a USB 3.1 SATA enclosure:

  - before: plugged in at 09:20 with 0000:7d:00.0 runtime suspended, still
    invisible at 09:21 with PME_Status latched at 1; only appeared when
    0000:7d:00.0 was forced to power/control=on.
  - with pcie_ports=native (which reaches the same code path in
    get_port_device_capability()): pcie_pme bound to 5 root ports, and the
    same enclosure enumerated in the same second it was plugged in, 66 s
    after the controller had suspended, with nothing forced.
  - with this patch, nothing forced: pcie_pme bound to 5 root ports and the
    _OSC line now reads "OS assumes control of [PCIeHotplug SHPCHotplug PME
    AER PCIeCapability LTR DPC]".  The enclosure was unplugged at 20:42:13,
    0000:7d:00.0 runtime suspended to D3hot, and on plugging it back in at
    20:43:06 (53 s later) the root port took a PME interrupt and the device
    enumerated in the same second.
  - wifi, internal keyboard, touchbar and audio all came up; 66 warnings
    and 45 errors during boot, against 65/43 on the distribution kernel.

One rough edge, reproducible on both boots: the port driver logs
"PME: Spurious native interrupt!" right before the device is resumed.
pcie_pme_handle_request() falls back to pcie_pme_walk_bus() when the root
port reports its own requester ID without PCI_PM_CTRL_PME_STATUS set, and
that walk skips PCIe devices, so the xHCI is never attributed.  The device
is still resumed and the wakeup works, but attributing PMEs from PCIe
devices behind a switch looks like a separate shortcoming; it is not
addressed here.

Boot with pcie_ports=native also showed no new AER/DPC activity and
slightly fewer warnings than a boot without it, so taking the remaining
control bit does not appear to disturb anything else on this machine.

Fixes: 7bc5a2bad0b8 ("ACPI: Support _OSI("Darwin") correctly")
Signed-off-by: Francisco Beltrán Millalén <fbeltranmillalen@gmail.com>
---
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -568,9 +568,14 @@
 	 * Apple always return failure on _OSC calls when _OSI("Darwin") has
 	 * been called successfully. We know the feature set supported by the
 	 * platform, so avoid calling _OSC at all
+	 *
+	 * Assume control of the same features that would have been requested,
+	 * PCIe PME included.  Leaving PME out disables the PME service for
+	 * every root port, and nothing takes over: a device that runtime
+	 * suspends asserts PME# and is never resumed.
 	 */
 	if (x86_apple_machine) {
-		root->osc_control_set = ~OSC_PCI_EXPRESS_PME_CONTROL;
+		root->osc_control_set = calculate_control();
 		decode_osc_control(root, "OS assumes control of",
 				   root->osc_control_set);
 		return;