Re: [PATCH][RFC] PCI: Workaround to enable poweroff on Mac Pro 11

[Chen Yu <yu.c.chen@intel.com>]

Hi Bjorn,

On 2016年05月31日 21:16, Bjorn Helgaas wrote:
> On Tue, May 31, 2016 at 03:18:02PM +0800, Chen Yu wrote:
>> On 2016年05月31日 15:00, Yinghai Lu wrote:
>>> On Mon, May 30, 2016 at 8:24 PM, Chen Yu <yu.c.chen@intel.com> wrote:
>>>
>>>> and then in pcibios_assign_resources, 0000:00:1c.0 tries to allocate minimal
>>>> resource window and then update related base/limit registers:
>>>>
>>>> [    0.865342] pci 0000:00:1c.0: bridge window [io  0x1000-0x0fff] to [bus
>>>> 02] add_size 1000
>>>> [    0.865343] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff
>>>> 64bit pref] to [bus 02] add_size 200000 add_align 100000
>>>> [    0.865344] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff]
>>>> to [bus 02] add_size 200000 add_align 100000
>>>>
>>> That is for hotplug bridge, then we could use following instead.
>>>
>>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>>> index ee72ebe..d3ec833 100644
>>> --- a/drivers/pci/quirks.c
>>> +++ b/drivers/pci/quirks.c
>>> @@ -2775,6 +2775,13 @@ static void quirk_hotplug_bridge(struct pci_dev *dev)
>>>
>>>   DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HINT, 0x0020, quirk_hotplug_bridge);
>>>
>>> +static void quirk_hotplug_bridge_skip(struct pci_dev *dev)
>>> +{
>>> +       dev->is_hotplug_bridge = 0;
>>> +}
>>> +
>>> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10,
>>> quirk_hotplug_bridge_skip);
>>> +
>>>   /*
>>>    * This is a quirk for the Ricoh MMC controller found as a part of
>>>    * some mulifunction chips.
>> Good idea, but in this way we might not have io window allocated for
>> it?I'm not sure
>> if this would break wifi,etc, I'll suggest reporters to have a try.
> Let's figure out the root cause before trying more random fixes.  I
> have the same objection to the patch above.  No doubt there are many
> ways we could "fix" this, but unless we know the root cause, we're
> likely to make a change that's not a complete fix or will cause other
> issues in the future.
>
I just let the reporter  paste their lspci in Mac OS, it looks that Mac 
OS also
does not allocate any resource for this broken pci bridge, and other pci
devices have almost the same resource region as it is in linux, so I think
this is an evidence that Apple does not want to use this firmware for now,
maybe reserved for future use, declaim resource for this pci bridge might
cause unpredictable result, how about adding a dmi+pci quirk for this
special platform?

lspci result from Mac OS, there's no resource behind this bridge:
https://bugzilla.kernel.org/attachment.cgi?id=219321


thanks,
Yu