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

2017-06-30 Thread Bjorn Helgaas 
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 :00:1c.0 reassigns its
> > > > mm windows to ([mem 0x7fa0-0x7fbf] and
> > > > [mem 0x7fc0-0x7fdf 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 
> > > > Cc: Rafael J. Wysocki 
> > > > Cc: Lukas Wunner 
> > > > Signed-off-by: Chen Yu 
> > > > ---
> > > >  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 0x7fa0 - 0x7fbf]
> > > > + * [mem 0x7fc0-0x7fdf 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 
> > > 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 0x7fa0-0x7fbf] 
> > > 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 0x7fa0-0x7fbf] for the 
> > > memory
> > > window, and poweroff and suspend-to-RAM don't work after this 
> > > assignment.
> > > 
> > > Linux does a soft

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

2017-06-30 Thread Bjorn Helgaas 
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 :00:1c.0 reassigns its
> > > > mm windows to ([mem 0x7fa0-0x7fbf] and
> > > > [mem 0x7fc0-0x7fdf 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 
> > > > Cc: Rafael J. Wysocki 
> > > > Cc: Lukas Wunner 
> > > > Signed-off-by: Chen Yu 
> > > > ---
> > > >  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 0x7fa0 - 0x7fbf]
> > > > + * [mem 0x7fc0-0x7fdf 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 
> > > 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 0x7fa0-0x7fbf] 
> > > 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 0x7fa0-0x7fbf] 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

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

2017-06-29 Thread Chen Yu 
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 :00:1c.0 reassigns its
> > > mm windows to ([mem 0x7fa0-0x7fbf] and
> > > [mem 0x7fc0-0x7fdf 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 
> > > Cc: Rafael J. Wysocki 
> > > Cc: Lukas Wunner 
> > > Signed-off-by: Chen Yu 
> > > ---
> > >  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 0x7fa0 - 0x7fbf]
> > > + * [mem 0x7fc0-0x7fdf 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 
> > 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 0x7fa0-0x7fbf] 
> > 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 0x7fa0-0x7fbf] 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 
> > 0x7fa0-0x7fbf].
> >   - When Linux assigns [mem

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

2017-06-29 Thread Chen Yu 
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 :00:1c.0 reassigns its
> > > mm windows to ([mem 0x7fa0-0x7fbf] and
> > > [mem 0x7fc0-0x7fdf 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 
> > > Cc: Rafael J. Wysocki 
> > > Cc: Lukas Wunner 
> > > Signed-off-by: Chen Yu 
> > > ---
> > >  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 0x7fa0 - 0x7fbf]
> > > + * [mem 0x7fc0-0x7fdf 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 
> > 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 0x7fa0-0x7fbf] 
> > 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 0x7fa0-0x7fbf] 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 
> > 0x7fa0-0x7fbf].
> >   - When Linux assigns [mem 0x7fa0-0x7fbf] to the 00:1c.0 Port, 
> > it
> > covers up whatever the SMI handler uses, so

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

2017-06-29 Thread Bjorn Helgaas 
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 :00:1c.0 reassigns its
> > mm windows to ([mem 0x7fa0-0x7fbf] and
> > [mem 0x7fc0-0x7fdf 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 
> > Cc: Rafael J. Wysocki 
> > Cc: Lukas Wunner 
> > Signed-off-by: Chen Yu 
> > ---
> >  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 0x7fa0 - 0x7fbf]
> > + * [mem 0x7fc0-0x7fdf 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 
> 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 0x7fa0-0x7fbf] 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 0x7fa0-0x7fbf] 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 
> 0x7fa0-0x7fbf].
>   - When Linux assigns [mem 0x7fa0-0x7fbf] 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 0x7fa0-0x7fbf] space to it.
> 
> Note that we

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

2017-06-29 Thread Bjorn Helgaas 
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 :00:1c.0 reassigns its
> > mm windows to ([mem 0x7fa0-0x7fbf] and
> > [mem 0x7fc0-0x7fdf 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 
> > Cc: Rafael J. Wysocki 
> > Cc: Lukas Wunner 
> > Signed-off-by: Chen Yu 
> > ---
> >  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 0x7fa0 - 0x7fbf]
> > + * [mem 0x7fc0-0x7fdf 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 
> 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 0x7fa0-0x7fbf] 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 0x7fa0-0x7fbf] 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 
> 0x7fa0-0x7fbf].
>   - When Linux assigns [mem 0x7fa0-0x7fbf] 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 0x7fa0-0x7fbf] 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

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

2017-06-29 Thread Bjorn Helgaas 
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 :00:1c.0 reassigns its
> mm windows to ([mem 0x7fa0-0x7fbf] and
> [mem 0x7fc0-0x7fdf 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 
> Cc: Rafael J. Wysocki 
> Cc: Lukas Wunner 
> Signed-off-by: Chen Yu 
> ---
>  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 0x7fa0 - 0x7fbf]
> + * [mem 0x7fc0-0x7fdf 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 
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 0x7fa0-0x7fbf] 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 0x7fa0-0x7fbf] 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 
0x7fa0-0x7fbf].
  - When Linux assigns [mem 0x7fa0-0x7fbf] 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 0x7fa0-0x7fbf] 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 
[bhelgaas: limit to device

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

2017-06-29 Thread Bjorn Helgaas 
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 :00:1c.0 reassigns its
> mm windows to ([mem 0x7fa0-0x7fbf] and
> [mem 0x7fc0-0x7fdf 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 
> Cc: Rafael J. Wysocki 
> Cc: Lukas Wunner 
> Signed-off-by: Chen Yu 
> ---
>  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 0x7fa0 - 0x7fbf]
> + * [mem 0x7fc0-0x7fdf 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 
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 0x7fa0-0x7fbf] 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 0x7fa0-0x7fbf] 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 
0x7fa0-0x7fbf].
  - When Linux assigns [mem 0x7fa0-0x7fbf] 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 0x7fa0-0x7fbf] 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 
[bhelgaas: limit to device 00:1c.0, add printk, changelog, comment]
Signed-off-by: Bjorn Helgaas 
Cc: Rafael J. Wysocki 
Cc: Lukas Wunner

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

2016-09-28 Thread Bjorn Helgaas 
On Mon, Sep 05, 2016 at 12:01:21PM +0800, Chen Yu wrote:
> On Fri, Sep 02, 2016 at 11:25:27AM -0500, Bjorn Helgaas wrote:
> > On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner 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 :00:1c.0 reassigns its
> > > > mm windows to ([mem 0x7fa0-0x7fbf] and
> > > > [mem 0x7fc0-0x7fdf 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.
> > > 
> > > To provide a bit more context:
> > > 
> > > The root port in question (:00:1c.0) is not listed in the DSDT.
> > > On macOS, only devices present in the ACPI namespace are incorporated
> > > into the I/O Kit registry. Consequently macOS pretends that this root
> > > port doesn't exist. It's not listed in the "ioreg -l" output and thus
> > > no driver is attached to this device.
> > > 
> > > So what we're dealing with is sloppiness on the part of Apple:
> > > Some engineer probably forgot to disable this unused root port
> > > and they didn't notice it during testing because their OS ignores
> > > such devices.
> > > 
> > > We could in principle achieve the same behaviour by adding a PCI
> > > device only if it has an ACPI companion, perhaps quirk this only
> > > to Macs. I'm not sure if that's the right thing to do though.
> > > What if they hide devices from macOS but we want to access them
> > > on Linux?
> > > 
> > > What's really odd is that changing *memory* windows affects
> > > accessibility of *I/O ports*.
> > > 
> > > One theory would be that I/O ports are somehow mapped into memory.
> > > The GPIO pins of Intel chipsets are usually accessible through
> > > I/O ports, but I've recently looked at the DSDT of the newest
> > > MacBook9,1 (2016) and it looks like they're now accessed through
> > > SystemMemory instead of SystemIO. Perhaps someone at Intel knows
> > > about these intricacies of their chipsets.
> > 
> > Hey, look, Chen Yu works at Intel :)
> >
> Ah yes, please give me some time and I'll try to search for related info
> and give feeback later.

Any news on this?  I was really hoping to make some progress on
this for v4.9, but time is running out.

Bjorn

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

2016-09-28 Thread Bjorn Helgaas 
On Mon, Sep 05, 2016 at 12:01:21PM +0800, Chen Yu wrote:
> On Fri, Sep 02, 2016 at 11:25:27AM -0500, Bjorn Helgaas wrote:
> > On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner 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 :00:1c.0 reassigns its
> > > > mm windows to ([mem 0x7fa0-0x7fbf] and
> > > > [mem 0x7fc0-0x7fdf 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.
> > > 
> > > To provide a bit more context:
> > > 
> > > The root port in question (:00:1c.0) is not listed in the DSDT.
> > > On macOS, only devices present in the ACPI namespace are incorporated
> > > into the I/O Kit registry. Consequently macOS pretends that this root
> > > port doesn't exist. It's not listed in the "ioreg -l" output and thus
> > > no driver is attached to this device.
> > > 
> > > So what we're dealing with is sloppiness on the part of Apple:
> > > Some engineer probably forgot to disable this unused root port
> > > and they didn't notice it during testing because their OS ignores
> > > such devices.
> > > 
> > > We could in principle achieve the same behaviour by adding a PCI
> > > device only if it has an ACPI companion, perhaps quirk this only
> > > to Macs. I'm not sure if that's the right thing to do though.
> > > What if they hide devices from macOS but we want to access them
> > > on Linux?
> > > 
> > > What's really odd is that changing *memory* windows affects
> > > accessibility of *I/O ports*.
> > > 
> > > One theory would be that I/O ports are somehow mapped into memory.
> > > The GPIO pins of Intel chipsets are usually accessible through
> > > I/O ports, but I've recently looked at the DSDT of the newest
> > > MacBook9,1 (2016) and it looks like they're now accessed through
> > > SystemMemory instead of SystemIO. Perhaps someone at Intel knows
> > > about these intricacies of their chipsets.
> > 
> > Hey, look, Chen Yu works at Intel :)
> >
> Ah yes, please give me some time and I'll try to search for related info
> and give feeback later.

Any news on this?  I was really hoping to make some progress on
this for v4.9, but time is running out.

Bjorn

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

2016-09-04 Thread Chen Yu 
On Fri, Sep 02, 2016 at 11:25:27AM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner 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 :00:1c.0 reassigns its
> > > mm windows to ([mem 0x7fa0-0x7fbf] and
> > > [mem 0x7fc0-0x7fdf 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.
> > 
> > To provide a bit more context:
> > 
> > The root port in question (:00:1c.0) is not listed in the DSDT.
> > On macOS, only devices present in the ACPI namespace are incorporated
> > into the I/O Kit registry. Consequently macOS pretends that this root
> > port doesn't exist. It's not listed in the "ioreg -l" output and thus
> > no driver is attached to this device.
> > 
> > So what we're dealing with is sloppiness on the part of Apple:
> > Some engineer probably forgot to disable this unused root port
> > and they didn't notice it during testing because their OS ignores
> > such devices.
> > 
> > We could in principle achieve the same behaviour by adding a PCI
> > device only if it has an ACPI companion, perhaps quirk this only
> > to Macs. I'm not sure if that's the right thing to do though.
> > What if they hide devices from macOS but we want to access them
> > on Linux?
> > 
> > What's really odd is that changing *memory* windows affects
> > accessibility of *I/O ports*.
> > 
> > One theory would be that I/O ports are somehow mapped into memory.
> > The GPIO pins of Intel chipsets are usually accessible through
> > I/O ports, but I've recently looked at the DSDT of the newest
> > MacBook9,1 (2016) and it looks like they're now accessed through
> > SystemMemory instead of SystemIO. Perhaps someone at Intel knows
> > about these intricacies of their chipsets.
> 
> Hey, look, Chen Yu works at Intel :)
>
Ah yes, please give me some time and I'll try to search for related info
and give feeback later.
> This apparent connection between memory windows and I/O port
> accessibility is indeed very concerning.
> 
> I know there are PCI host bridges with windows that translate CPU
> memory accesses into PCI I/O port accesses.  If this is one of them,
> and it has such a window enabled at the address we happened to choose
> for the mem window, that would be a problem.
> 
> I assume this would be documented somewhere in the chipset datasheet.
> 
> > If I/O ports are indeed mapped into memory, we need to find a way
> > to identify and reserve that region. So while this patch seems
> > like a workable and sufficiently small fix, it might mask a larger
> > underlying issue. It's certainly a problem though that these
> > machines currently cannot power off or suspend.
> > 
> > FWIW, we have a somewhat similar issue with the Apple gmux
> > (a microcontroller built into dual GPU MacBook Pros). That chip
> > is attached to the LPC bus and accessed through I/O ports.
> > It turns out that once VGA IO is locked to the discrete GPU
> > using vgaarb, gmux' I/O ports suddenly become inaccessible.
> > Apparently its I/O ports are routed to the secondary PCI bus
> > to which the discrete GPU is connected, and no longer to the
> > root bus on which the LPC bridge resides. However gmux' I/O ports
> > are in the 0x700-0x7ff range, whereas the VGA registers are in
> > the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
> > of Intel chipsets with regards to I/O accessibility.
> >

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

2016-09-04 Thread Chen Yu 
On Fri, Sep 02, 2016 at 11:25:27AM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner 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 :00:1c.0 reassigns its
> > > mm windows to ([mem 0x7fa0-0x7fbf] and
> > > [mem 0x7fc0-0x7fdf 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.
> > 
> > To provide a bit more context:
> > 
> > The root port in question (:00:1c.0) is not listed in the DSDT.
> > On macOS, only devices present in the ACPI namespace are incorporated
> > into the I/O Kit registry. Consequently macOS pretends that this root
> > port doesn't exist. It's not listed in the "ioreg -l" output and thus
> > no driver is attached to this device.
> > 
> > So what we're dealing with is sloppiness on the part of Apple:
> > Some engineer probably forgot to disable this unused root port
> > and they didn't notice it during testing because their OS ignores
> > such devices.
> > 
> > We could in principle achieve the same behaviour by adding a PCI
> > device only if it has an ACPI companion, perhaps quirk this only
> > to Macs. I'm not sure if that's the right thing to do though.
> > What if they hide devices from macOS but we want to access them
> > on Linux?
> > 
> > What's really odd is that changing *memory* windows affects
> > accessibility of *I/O ports*.
> > 
> > One theory would be that I/O ports are somehow mapped into memory.
> > The GPIO pins of Intel chipsets are usually accessible through
> > I/O ports, but I've recently looked at the DSDT of the newest
> > MacBook9,1 (2016) and it looks like they're now accessed through
> > SystemMemory instead of SystemIO. Perhaps someone at Intel knows
> > about these intricacies of their chipsets.
> 
> Hey, look, Chen Yu works at Intel :)
>
Ah yes, please give me some time and I'll try to search for related info
and give feeback later.
> This apparent connection between memory windows and I/O port
> accessibility is indeed very concerning.
> 
> I know there are PCI host bridges with windows that translate CPU
> memory accesses into PCI I/O port accesses.  If this is one of them,
> and it has such a window enabled at the address we happened to choose
> for the mem window, that would be a problem.
> 
> I assume this would be documented somewhere in the chipset datasheet.
> 
> > If I/O ports are indeed mapped into memory, we need to find a way
> > to identify and reserve that region. So while this patch seems
> > like a workable and sufficiently small fix, it might mask a larger
> > underlying issue. It's certainly a problem though that these
> > machines currently cannot power off or suspend.
> > 
> > FWIW, we have a somewhat similar issue with the Apple gmux
> > (a microcontroller built into dual GPU MacBook Pros). That chip
> > is attached to the LPC bus and accessed through I/O ports.
> > It turns out that once VGA IO is locked to the discrete GPU
> > using vgaarb, gmux' I/O ports suddenly become inaccessible.
> > Apparently its I/O ports are routed to the secondary PCI bus
> > to which the discrete GPU is connected, and no longer to the
> > root bus on which the LPC bridge resides. However gmux' I/O ports
> > are in the 0x700-0x7ff range, whereas the VGA registers are in
> > the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
> > of Intel chipsets with regards to I/O accessibility.
> >

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

2016-09-02 Thread Bjorn Helgaas 
On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner 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 :00:1c.0 reassigns its
> > mm windows to ([mem 0x7fa0-0x7fbf] and
> > [mem 0x7fc0-0x7fdf 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.
> 
> To provide a bit more context:
> 
> The root port in question (:00:1c.0) is not listed in the DSDT.
> On macOS, only devices present in the ACPI namespace are incorporated
> into the I/O Kit registry. Consequently macOS pretends that this root
> port doesn't exist. It's not listed in the "ioreg -l" output and thus
> no driver is attached to this device.
> 
> So what we're dealing with is sloppiness on the part of Apple:
> Some engineer probably forgot to disable this unused root port
> and they didn't notice it during testing because their OS ignores
> such devices.
> 
> We could in principle achieve the same behaviour by adding a PCI
> device only if it has an ACPI companion, perhaps quirk this only
> to Macs. I'm not sure if that's the right thing to do though.
> What if they hide devices from macOS but we want to access them
> on Linux?
> 
> What's really odd is that changing *memory* windows affects
> accessibility of *I/O ports*.
> 
> One theory would be that I/O ports are somehow mapped into memory.
> The GPIO pins of Intel chipsets are usually accessible through
> I/O ports, but I've recently looked at the DSDT of the newest
> MacBook9,1 (2016) and it looks like they're now accessed through
> SystemMemory instead of SystemIO. Perhaps someone at Intel knows
> about these intricacies of their chipsets.

Hey, look, Chen Yu works at Intel :)

This apparent connection between memory windows and I/O port
accessibility is indeed very concerning.

I know there are PCI host bridges with windows that translate CPU
memory accesses into PCI I/O port accesses.  If this is one of them,
and it has such a window enabled at the address we happened to choose
for the mem window, that would be a problem.

I assume this would be documented somewhere in the chipset datasheet.

> If I/O ports are indeed mapped into memory, we need to find a way
> to identify and reserve that region. So while this patch seems
> like a workable and sufficiently small fix, it might mask a larger
> underlying issue. It's certainly a problem though that these
> machines currently cannot power off or suspend.
> 
> FWIW, we have a somewhat similar issue with the Apple gmux
> (a microcontroller built into dual GPU MacBook Pros). That chip
> is attached to the LPC bus and accessed through I/O ports.
> It turns out that once VGA IO is locked to the discrete GPU
> using vgaarb, gmux' I/O ports suddenly become inaccessible.
> Apparently its I/O ports are routed to the secondary PCI bus
> to which the discrete GPU is connected, and no longer to the
> root bus on which the LPC bridge resides. However gmux' I/O ports
> are in the 0x700-0x7ff range, whereas the VGA registers are in
> the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
> of Intel chipsets with regards to I/O accessibility.
> 
> Best regards,
> 
> Lukas
> 
> > 
> > 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 
> > Cc: Rafael J. Wysocki 
> > Cc: Lukas Wunner 
> > Signed-off-by: Chen Yu 
> > ---
> >  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:

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

2016-09-02 Thread Bjorn Helgaas 
On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner 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 :00:1c.0 reassigns its
> > mm windows to ([mem 0x7fa0-0x7fbf] and
> > [mem 0x7fc0-0x7fdf 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.
> 
> To provide a bit more context:
> 
> The root port in question (:00:1c.0) is not listed in the DSDT.
> On macOS, only devices present in the ACPI namespace are incorporated
> into the I/O Kit registry. Consequently macOS pretends that this root
> port doesn't exist. It's not listed in the "ioreg -l" output and thus
> no driver is attached to this device.
> 
> So what we're dealing with is sloppiness on the part of Apple:
> Some engineer probably forgot to disable this unused root port
> and they didn't notice it during testing because their OS ignores
> such devices.
> 
> We could in principle achieve the same behaviour by adding a PCI
> device only if it has an ACPI companion, perhaps quirk this only
> to Macs. I'm not sure if that's the right thing to do though.
> What if they hide devices from macOS but we want to access them
> on Linux?
> 
> What's really odd is that changing *memory* windows affects
> accessibility of *I/O ports*.
> 
> One theory would be that I/O ports are somehow mapped into memory.
> The GPIO pins of Intel chipsets are usually accessible through
> I/O ports, but I've recently looked at the DSDT of the newest
> MacBook9,1 (2016) and it looks like they're now accessed through
> SystemMemory instead of SystemIO. Perhaps someone at Intel knows
> about these intricacies of their chipsets.

Hey, look, Chen Yu works at Intel :)

This apparent connection between memory windows and I/O port
accessibility is indeed very concerning.

I know there are PCI host bridges with windows that translate CPU
memory accesses into PCI I/O port accesses.  If this is one of them,
and it has such a window enabled at the address we happened to choose
for the mem window, that would be a problem.

I assume this would be documented somewhere in the chipset datasheet.

> If I/O ports are indeed mapped into memory, we need to find a way
> to identify and reserve that region. So while this patch seems
> like a workable and sufficiently small fix, it might mask a larger
> underlying issue. It's certainly a problem though that these
> machines currently cannot power off or suspend.
> 
> FWIW, we have a somewhat similar issue with the Apple gmux
> (a microcontroller built into dual GPU MacBook Pros). That chip
> is attached to the LPC bus and accessed through I/O ports.
> It turns out that once VGA IO is locked to the discrete GPU
> using vgaarb, gmux' I/O ports suddenly become inaccessible.
> Apparently its I/O ports are routed to the secondary PCI bus
> to which the discrete GPU is connected, and no longer to the
> root bus on which the LPC bridge resides. However gmux' I/O ports
> are in the 0x700-0x7ff range, whereas the VGA registers are in
> the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
> of Intel chipsets with regards to I/O accessibility.
> 
> Best regards,
> 
> Lukas
> 
> > 
> > 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 
> > Cc: Rafael J. Wysocki 
> > Cc: Lukas Wunner 
> > Signed-off-by: Chen Yu 
> > ---
> >  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 0x7fa0 - 0x7fbf]
> > + * [mem 0x7fc0-0x7fdf 64bit

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

2016-08-24 Thread Lukas Wunner 
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 :00:1c.0 reassigns its
> mm windows to ([mem 0x7fa0-0x7fbf] and
> [mem 0x7fc0-0x7fdf 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.

To provide a bit more context:

The root port in question (:00:1c.0) is not listed in the DSDT.
On macOS, only devices present in the ACPI namespace are incorporated
into the I/O Kit registry. Consequently macOS pretends that this root
port doesn't exist. It's not listed in the "ioreg -l" output and thus
no driver is attached to this device.

So what we're dealing with is sloppiness on the part of Apple:
Some engineer probably forgot to disable this unused root port
and they didn't notice it during testing because their OS ignores
such devices.

We could in principle achieve the same behaviour by adding a PCI
device only if it has an ACPI companion, perhaps quirk this only
to Macs. I'm not sure if that's the right thing to do though.
What if they hide devices from macOS but we want to access them
on Linux?

What's really odd is that changing *memory* windows affects
accessibility of *I/O ports*.

One theory would be that I/O ports are somehow mapped into memory.
The GPIO pins of Intel chipsets are usually accessible through
I/O ports, but I've recently looked at the DSDT of the newest
MacBook9,1 (2016) and it looks like they're now accessed through
SystemMemory instead of SystemIO. Perhaps someone at Intel knows
about these intricacies of their chipsets.

If I/O ports are indeed mapped into memory, we need to find a way
to identify and reserve that region. So while this patch seems
like a workable and sufficiently small fix, it might mask a larger
underlying issue. It's certainly a problem though that these
machines currently cannot power off or suspend.

FWIW, we have a somewhat similar issue with the Apple gmux
(a microcontroller built into dual GPU MacBook Pros). That chip
is attached to the LPC bus and accessed through I/O ports.
It turns out that once VGA IO is locked to the discrete GPU
using vgaarb, gmux' I/O ports suddenly become inaccessible.
Apparently its I/O ports are routed to the secondary PCI bus
to which the discrete GPU is connected, and no longer to the
root bus on which the LPC bridge resides. However gmux' I/O ports
are in the 0x700-0x7ff range, whereas the VGA registers are in
the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
of Intel chipsets with regards to I/O accessibility.

Best regards,

Lukas

> 
> 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 
> Cc: Rafael J. Wysocki 
> Cc: Lukas Wunner 
> Signed-off-by: Chen Yu 
> ---
>  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 0x7fa0 - 0x7fbf]
> + * [mem 0x7fc0-0x7fdf 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
>   * some mulifunction chips.
>  
> -- 
> 2.7.4
>

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

2016-08-24 Thread Lukas Wunner 
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 :00:1c.0 reassigns its
> mm windows to ([mem 0x7fa0-0x7fbf] and
> [mem 0x7fc0-0x7fdf 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.

To provide a bit more context:

The root port in question (:00:1c.0) is not listed in the DSDT.
On macOS, only devices present in the ACPI namespace are incorporated
into the I/O Kit registry. Consequently macOS pretends that this root
port doesn't exist. It's not listed in the "ioreg -l" output and thus
no driver is attached to this device.

So what we're dealing with is sloppiness on the part of Apple:
Some engineer probably forgot to disable this unused root port
and they didn't notice it during testing because their OS ignores
such devices.

We could in principle achieve the same behaviour by adding a PCI
device only if it has an ACPI companion, perhaps quirk this only
to Macs. I'm not sure if that's the right thing to do though.
What if they hide devices from macOS but we want to access them
on Linux?

What's really odd is that changing *memory* windows affects
accessibility of *I/O ports*.

One theory would be that I/O ports are somehow mapped into memory.
The GPIO pins of Intel chipsets are usually accessible through
I/O ports, but I've recently looked at the DSDT of the newest
MacBook9,1 (2016) and it looks like they're now accessed through
SystemMemory instead of SystemIO. Perhaps someone at Intel knows
about these intricacies of their chipsets.

If I/O ports are indeed mapped into memory, we need to find a way
to identify and reserve that region. So while this patch seems
like a workable and sufficiently small fix, it might mask a larger
underlying issue. It's certainly a problem though that these
machines currently cannot power off or suspend.

FWIW, we have a somewhat similar issue with the Apple gmux
(a microcontroller built into dual GPU MacBook Pros). That chip
is attached to the LPC bus and accessed through I/O ports.
It turns out that once VGA IO is locked to the discrete GPU
using vgaarb, gmux' I/O ports suddenly become inaccessible.
Apparently its I/O ports are routed to the secondary PCI bus
to which the discrete GPU is connected, and no longer to the
root bus on which the LPC bridge resides. However gmux' I/O ports
are in the 0x700-0x7ff range, whereas the VGA registers are in
the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
of Intel chipsets with regards to I/O accessibility.

Best regards,

Lukas

> 
> 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 
> Cc: Rafael J. Wysocki 
> Cc: Lukas Wunner 
> Signed-off-by: Chen Yu 
> ---
>  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 0x7fa0 - 0x7fbf]
> + * [mem 0x7fc0-0x7fdf 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
>   * some mulifunction chips.
>  
> -- 
> 2.7.4
>

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

2016-08-19 Thread Chen Yu 
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 :00:1c.0 reassigns its
mm windows to ([mem 0x7fa0-0x7fbf] and
[mem 0x7fc0-0x7fdf 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 
Cc: Rafael J. Wysocki 
Cc: Lukas Wunner 
Signed-off-by: Chen Yu 
---
 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 0x7fa0 - 0x7fbf]
+ * [mem 0x7fc0-0x7fdf 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
  * some mulifunction chips.
 
-- 
2.7.4

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

2016-08-19 Thread Chen Yu 
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 :00:1c.0 reassigns its
mm windows to ([mem 0x7fa0-0x7fbf] and
[mem 0x7fc0-0x7fdf 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 
Cc: Rafael J. Wysocki 
Cc: Lukas Wunner 
Signed-off-by: Chen Yu 
---
 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 0x7fa0 - 0x7fbf]
+ * [mem 0x7fc0-0x7fdf 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
  * some mulifunction chips.
 
-- 
2.7.4