From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chen Yu Subject: Re: [PATCH][RFC] PCI: Workaround to enable poweroff on Mac Pro 11 Date: Tue, 31 May 2016 11:29:39 +0800 Message-ID: <574D0523.3020009@intel.com> References: <1464604404-11257-1-git-send-email-yu.c.chen@intel.com> <20160530213305.GA21322@localhost> <20160530221123.GA13535@wunner.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mga01.intel.com ([192.55.52.88]:60286 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752703AbcEaDWe (ORCPT ); Mon, 30 May 2016 23:22:34 -0400 In-Reply-To: <20160530221123.GA13535@wunner.de> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Lukas Wunner , Bjorn Helgaas Cc: linux-pci@vger.kernel.org, linux-arch@vger.kernel.org, Bjorn Helgaas , Arnd Bergmann , "Rafael J . Wysocki" , Len Brown , Mika Westerberg , Yinghai Lu Hi Lukas, On 2016=E5=B9=B405=E6=9C=8831=E6=97=A5 06:11, Lukas Wunner wrote: > On Mon, May 30, 2016 at 04:33:05PM -0500, Bjorn Helgaas wrote: >> On Mon, May 30, 2016 at 06:33:24PM +0800, Chen Yu wrote: >>> Currently there are many people reported that they can not >>> do a poweroff nor a suspend to memory on their Mac Pro 11. >>> After some investigations it was found that, once the PCI bridge >>> 0000:00:1c.0 reassigns its mm windows([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 memory(S3) works. >>> >>> I don't know why setting the base/limit of PCI bridge mem resource >>> would affect another io resource region, so this quirk just simply >>> bypass the assignment of these mm resources on 0000:00:1c.0, by >>> resetting the resource flag to 0 before updating the base/limit reg= isters. >>> This patch also introduces a new pci fixup phase before the actual = bridge >>> resource assignment. >> Split the new fixup phase into a separate patch. >> >> I'm doubtful about this because we don't understand the root cause. > Agreed. > > >>> +} >>> +DECLARE_PCI_FIXUP_ASSIGN(PCI_VENDOR_ID_INTEL, 0x8c10, quirk_mac_di= sable_mmio_bar); >> Is this device *only* used on the Mac Pro 11? http://pci-ids.ucs.cz >> says "8 Series/C220 Series Chipset Family PCI Express Root Port #1", >> which sounds pretty generic. > It's a root port of a standard Haswell chipset. > > This concerns the Mac*Book*Pro11 (not MacPro11), and apparently only > the two models introduced 2015, MacBookPro11,4 and MacBookPro11,5 > (can be queried with DMI). I've never heard of issues like this on th= e > 2013/2014 models (MacBookPro11,1 to 11,3). > > Looking at the lspci output of the MacBookPro11,4 I notice that the > root port in question, 00:1c.0, has secondary bus 02 below it, but > there are no devices listed on that bus: > https://bugzilla.kernel.org/attachment.cgi?id=3D218181 > > On the MacBookPro11,5, there's bus 03 below that port, but likewise > without any devices: > https://launchpadlibrarian.net/222477783/Lspci.txt > > It looks like this root port is unused, so perhaps the best option > is to disable it as if it were an appendix. I.e., don't scan it at al= l, > put it into D3 and leave it alone. I used to bypass the probe for this pci bridge: https://bugzilla.kernel.org/attachment.cgi?id=3D216661 , but it looks like although poweroff works however the wifi and facetime are broken: https://bugzilla.kernel.org/show_bug.cgi?id=3D103211#c109 Thanks, Yu