Patch "PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11" has been added to the 4.12-stable tree
Subsystems (3)
This is a note to let you know that I've just added the patch titled
PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11
to the 4.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
pci-work-around-poweroff-suspend-to-ram-issue-on-macbook-pro-11.patch
and it can be found in the queue-4.12 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
13cfc732160f7bc7e596128ce34cda361c556966Mon Sep 17 00:00:00 2001
From: Bjorn Helgaas <[email protected]>
Date: Fri, 19 Aug 2016 16:30:25 +0800
Subject: PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11
From: Bjorn Helgaas <[email protected]>
commit 13cfc732160f7bc7e596128ce34cda361c556966 upstream.
Neither soft poweroff (transition to ACPI power state S5) nor suspend-to-RAM (transition to state S3) works on the Macbook Pro 11,4 and 11,5.
The problem is related to the [mem 0x7fa00000-0x7fbfffff] space. When we use that space, e.g., by assigning it to the 00:1c.0 Root Port, the ACPI Power Management 1 Control Register (PM1_CNT) at [io 0x1804] doesn't work anymore.
Linux does a soft poweroff (transition to S5) by writing to PM1_CNT. The theory about why this doesn't work is:
- The write to PM1_CNT causes an SMI
- The BIOS SMI handler depends on something in
[mem 0x7fa00000-0x7fbfffff]
- When Linux assigns [mem 0x7fa00000-0x7fbfffff] to the 00:1c.0 Port, it covers up whatever the SMI handler uses, so the SMI handler no longer works correctly
Reserve the [mem 0x7fa00000-0x7fbfffff] space so we don't assign it to anything.
This is voodoo programming, since we don't know what the real conflict is, but we've failed to find the root cause.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
--- arch/x86/pci/fixup.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)
arch/x86/pci/fixup.c +32 -0
@@ -571,3 +571,35 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INDECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_INTEL ,0x6f60 , pci_invalid_bar);DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_INTEL ,0x6fa0 , pci_invalid_bar);DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_INTEL ,0x6fc0 , pci_invalid_bar); + +/* +* Apple MacBook Pro: Avoid [mem 0x7fa00000-0x7fbfffff] +* +* Using the [mem 0x7fa00000-0x7fbfffff] region, e.g., by assigning it to +* the 00:1c.0 Root Port, causes a conflict with [io 0x1804], which is used +* for soft poweroff and suspend-to-RAM. +* +* As far as we know, this is related to the address space, not to the Root +* Port itself. Attaching the quirk to the Root Port is a convenience, but +* it could probably also be a standalone DMI quirk. +* +* https://bugzilla.kernel.org/show_bug.cgi?id=103211 +*/ +static void quirk_apple_mbp_poweroff (struct pci_dev *pdev) +{ +struct device *dev = &pdev->dev; +struct resource *res; + +if ((!dmi_match (DMI_PRODUCT_NAME ,"MacBookPro11,4" ) && + !dmi_match (DMI_PRODUCT_NAME ,"MacBookPro11,5" )) || + pdev->bus->number !=0 || pdev->devfn !=PCI_DEVFN (0x1c ,0 )) +return ; + + res =request_mem_region (0x7fa00000 ,0x200000 , +"MacBook Pro poweroff workaround" ); +if (res) +dev_info (dev,"claimed %s %pR\n" , res->name, res); +else +dev_info (dev,"can't work around MacBook Pro poweroff issue\n" ); +} +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x8c10 , quirk_apple_mbp_poweroff);
Patches currently in stable-queue which might be from [email protected] are
queue-4.12/pci-msi-ignore-affinity-if-pre-post-vector-count-is-more-than-min_vecs.patch queue-4.12/pci-work-around-poweroff-suspend-to-ram-issue-on-macbook-pro-11.patch queue-4.12/pci-rockchip-use-normal-register-bank-for-config-accessors.patch queue-4.12/pci-vmd-move-srcu-cleanup-after-bus-child-device-removal.patch queue-4.12/pci-pm-restore-the-status-of-pci-devices-across-hibernation.patch