On Fri, Jun 30, 2017 at 11:06:46AM +0800, Chen Yu wrote: > Hi Bjorn, > On Thu, Jun 29, 2017 at 09:39:31PM -0500, Bjorn Helgaas wrote: > > On Thu, Jun 29, 2017 at 02:19:26PM -0500, Bjorn Helgaas wrote: > > > On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote: > > > > People reported that they can not do a poweroff nor a > > > > suspend to ram on their Mac Pro 11. After some investigations > > > > it was found that, once the PCI bridge 0000:00:1c.0 reassigns its > > > > mm windows to ([mem 0x7fa00000-0x7fbfffff] and > > > > [mem 0x7fc00000-0x7fdfffff 64bit pref]), the region of ACPI > > > > io resource 0x1804 becomes unaccessible immediately, where the > > > > ACPI Sleep register is located, as a result neither poweroff(S5) > > > > nor suspend to ram(S3) works. > > > > > > > > As suggested by Bjorn, further testing shows that, there is an > > > > unreported device may be (using) conflict with above aperture, > > > > which brings unpredictable result such as the failure of accessing > > > > the io port, which blocks the poweroff(S5). Besides if we reassign > > > > the memory aperture to the other place, the poweroff works again. > > > > > > > > As we do not find any resource declared in _CRS which contain above > > > > memory aperture, and Mac OS does not use this pci bridge neither, we > > > > choose a simple workaround to clear the hotplug flag(suggested by > > > > Yinghai Lu), thus do not allocate any resource for this pci bridge, > > > > and thereby no conflict anymore. > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211 > > > > Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > > > > Cc: Rafael J. Wysocki <rafael@xxxxxxxxxx> > > > > Cc: Lukas Wunner <lukas@xxxxxxxxx> > > > > Signed-off-by: Chen Yu <yu.c.chen@xxxxxxxxx> > > > > --- > > > > drivers/pci/quirks.c | 20 ++++++++++++++++++++ > > > > 1 file changed, 20 insertions(+) > > > > > > > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > > > > index 37ff015..04bbdba 100644 > > > > --- a/drivers/pci/quirks.c > > > > +++ b/drivers/pci/quirks.c > > > > @@ -2776,6 +2776,26 @@ static void quirk_hotplug_bridge(struct pci_dev *dev) > > > > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HINT, 0x0020, quirk_hotplug_bridge); > > > > > > > > /* > > > > + * Apple: Avoid programming the memory/io aperture of 00:1c.0 > > > > + * > > > > + * BIOS does not declare any resource for 00:1c.0, but with > > > > + * hotplug flag set, thus the OS allocates: > > > > + * [mem 0x7fa00000 - 0x7fbfffff] > > > > + * [mem 0x7fc00000-0x7fdfffff 64bit pref] > > > > + * which is conflict with an unreported device, which > > > > + * causes unpredictable result such as accessing io port. > > > > + * So clear the hotplug flag to work around it. > > > > + */ > > > > +static void quirk_apple_mbp_poweroff(struct pci_dev *dev) > > > > +{ > > > > + if (dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,4") || > > > > + dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,5")) > > > > + dev->is_hotplug_bridge = 0; > > > > +} > > > > + > > > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, quirk_apple_mbp_poweroff); > > > > + > > > > +/* > > > > * This is a quirk for the Ricoh MMC controller found as a part of > > > > > > I give up. We're not making any progress on this. I propose the > > > following patch for v4.13. This is slightly modified to: > > > > > > - move to arch/x86/pci/fixups.c, since I think this is specific to > > > x86 > > > > > > - only clear dev->is_hotplug_bridge for the 00:1c.0 bridge, since > > > these systems contain other bridges where I think we *do* want to > > > support hotplug, e.g., the Thunderbolt bridge at 09:00.0 (from > > > https://bugzilla.kernel.org/attachment.cgi?id=210611) > > > > > > - log a note in dmesg about what we're doing > > > > > > commit f7bf6baa11b84534d0b7f5ceee06e3349948c853 > > > Author: Chen Yu <yu.c.chen@xxxxxxxxx> > > > Date: Fri Aug 19 16:30:25 2016 +0800 > > > > > > PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11 > > > > > > 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 assigning the [mem 0x7fa00000-0x7fbfffff] space > > > to the 00:1c.0 Root Port. This port isn't connected to anything, but it > > > advertises hotplug support in its PCIe Capability. Initially it has no > > > windows assigned, and if Linux leaves it that way, poweroff and > > > suspend-to-RAM work fine. > > > > > > Since the port supports hotplug, Linux assigns windows for future hot-added > > > devices. We currently assign [mem 0x7fa00000-0x7fbfffff] for the memory > > > window, and poweroff and suspend-to-RAM don't work after this assignment. > > > > > > Linux does a soft poweroff (transition to S5) by writing to PM1_CNT at > > > [io 0x1804]. 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. > > > > > > Mark the 00:1c.0 bridge as not supporting hotplug, so we don't assign the > > > [mem 0x7fa00000-0x7fbfffff] space to it. > > > > > > Note that we don't know what the real conflict is, so other use of this > > > memory range by another device may cause similar problems. > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211 > > > Signed-off-by: Chen Yu <yu.c.chen@xxxxxxxxx> > > > [bhelgaas: limit to device 00:1c.0, add printk, changelog, comment] > > > Signed-off-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > > > Cc: Rafael J. Wysocki <rafael@xxxxxxxxxx> > > > Cc: Lukas Wunner <lukas@xxxxxxxxx> > > > > > > > This patch stinks, sorry. I'll try again tomorrow. The problem is > > the address space, not the device, so we should be able to do better > > than this. > It is a quite old bug and thanks for taking care of this :-). Do you mean > reserve the [mem 0x7fa00000-0x7fbfffff] thus no one could allocate this region? Yes, exactly. That seems like a more robust solution. I can't remember if we've tried that before or not. Likely we could narrow that down to a smaller region; I can't remember if we've done that, either.
