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

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

[Chen Yu]

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 registers.
This patch also introduces a new pci fixup phase before the actual bridge
resource assignment.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
Tested-by: Cedric Le Goater <clg@kaod.org>
Tested-by: pkozlov <pkozlov.vrn@gmail.com>
Tested-by: Zach Norman <zach@nor.mn>
Tested-by: Pablo Catalina <pablo.catalina@gmail.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
---
 drivers/pci/quirks.c              | 25 +++++++++++++++++++++++++
 drivers/pci/setup-bus.c           |  2 ++
 include/asm-generic/vmlinux.lds.h |  3 +++
 include/linux/pci.h               |  4 ++++
 scripts/mod/modpost.c             |  1 +
 5 files changed, 35 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index ee72ebe..e347047 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3370,6 +3370,8 @@ extern struct pci_fixup __start_pci_fixups_header[];
 extern struct pci_fixup __end_pci_fixups_header[];
 extern struct pci_fixup __start_pci_fixups_final[];
 extern struct pci_fixup __end_pci_fixups_final[];
+extern struct pci_fixup __start_pci_fixups_assign[];
+extern struct pci_fixup __end_pci_fixups_assign[];
 extern struct pci_fixup __start_pci_fixups_enable[];
 extern struct pci_fixup __end_pci_fixups_enable[];
 extern struct pci_fixup __start_pci_fixups_resume[];
@@ -3405,6 +3407,11 @@ void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev)
 		end = __end_pci_fixups_final;
 		break;
 
+	case pci_fixup_assign:
+		start = __start_pci_fixups_assign;
+		end = __end_pci_fixups_assign;
+		break;
+
 	case pci_fixup_enable:
 		start = __start_pci_fixups_enable;
 		end = __end_pci_fixups_enable;
@@ -4419,3 +4426,21 @@ static void quirk_intel_qat_vf_cap(struct pci_dev *pdev)
 	}
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
+
+/*
+ * On Mac Pro 11, the allocation of pci bridge memory resource
+ * broke ACPI Sleep Type register region.
+ */
+static void quirk_mac_disable_mmio_bar(struct pci_dev *dev)
+{
+	struct resource *b_res;
+
+	dev_info(&dev->dev, "[Quirk] Disable mmio on Mac Pro 11\n");
+	if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)
+		return;
+
+	b_res = &dev->resource[PCI_BRIDGE_RESOURCES];
+	b_res[1].flags = 0;
+	b_res[2].flags = 0;
+}
+DECLARE_PCI_FIXUP_ASSIGN(PCI_VENDOR_ID_INTEL, 0x8c10, quirk_mac_disable_mmio_bar);
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 55641a3..730d6fd 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1256,6 +1256,8 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct list_head *realloc_head)
 			additional_io_size  = pci_hotplug_io_size;
 			additional_mem_size = pci_hotplug_mem_size;
 		}
+
+		pci_fixup_device(pci_fixup_assign, bus->self);
 		/* Fall through */
 	default:
 		pbus_size_io(bus, realloc_head ? 0 : additional_io_size,
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 6a67ab9..3ba05f0 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -283,6 +283,9 @@
 		VMLINUX_SYMBOL(__start_pci_fixups_final) = .;		\
 		*(.pci_fixup_final)					\
 		VMLINUX_SYMBOL(__end_pci_fixups_final) = .;		\
+		VMLINUX_SYMBOL(__start_pci_fixups_assign) = .;		\
+		*(.pci_fixup_assign)					\
+		VMLINUX_SYMBOL(__end_pci_fixups_assign) = .;		\
 		VMLINUX_SYMBOL(__start_pci_fixups_enable) = .;		\
 		*(.pci_fixup_enable)					\
 		VMLINUX_SYMBOL(__end_pci_fixups_enable) = .;		\
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b67e4df..14a35bb 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1584,6 +1584,7 @@ enum pci_fixup_pass {
 	pci_fixup_early,	/* Before probing BARs */
 	pci_fixup_header,	/* After reading configuration header */
 	pci_fixup_final,	/* Final phase of device fixups */
+	pci_fixup_assign,	/* Before resource assignment */
 	pci_fixup_enable,	/* pci_enable_device() time */
 	pci_fixup_resume,	/* pci_device_resume() */
 	pci_fixup_suspend,	/* pci_device_suspend() */
@@ -1644,6 +1645,9 @@ enum pci_fixup_pass {
 #define DECLARE_PCI_FIXUP_FINAL(vendor, device, hook)			\
 	DECLARE_PCI_FIXUP_SECTION(.pci_fixup_final,			\
 		hook, vendor, device, PCI_ANY_ID, 0, hook)
+#define DECLARE_PCI_FIXUP_ASSIGN(vendor, device, hook)			\
+	DECLARE_PCI_FIXUP_SECTION(.pci_fixup_assign,			\
+		hook, vendor, device, PCI_ANY_ID, 0, hook)
 #define DECLARE_PCI_FIXUP_ENABLE(vendor, device, hook)			\
 	DECLARE_PCI_FIXUP_SECTION(.pci_fixup_enable,			\
 		hook, vendor, device, PCI_ANY_ID, 0, hook)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 48958d3..248acdb 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -877,6 +877,7 @@ static void check_section(const char *modname, struct elf_info *elf,
 
 #define ALL_PCI_INIT_SECTIONS	\
 	".pci_fixup_early", ".pci_fixup_header", ".pci_fixup_final", \
+	".pci_fixup_assign", \
 	".pci_fixup_enable", ".pci_fixup_resume", \
 	".pci_fixup_resume_early", ".pci_fixup_suspend"
 
-- 
2.7.4

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

[Bjorn Helgaas]

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 registers.
> 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.

> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
> Tested-by: Cedric Le Goater <clg@kaod.org>
> Tested-by: pkozlov <pkozlov.vrn@gmail.com>
> Tested-by: Zach Norman <zach@nor.mn>
> Tested-by: Pablo Catalina <pablo.catalina@gmail.com>
> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> ---
>  drivers/pci/quirks.c              | 25 +++++++++++++++++++++++++
>  drivers/pci/setup-bus.c           |  2 ++
>  include/asm-generic/vmlinux.lds.h |  3 +++
>  include/linux/pci.h               |  4 ++++
>  scripts/mod/modpost.c             |  1 +
>  5 files changed, 35 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index ee72ebe..e347047 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3370,6 +3370,8 @@ extern struct pci_fixup __start_pci_fixups_header[];
>  extern struct pci_fixup __end_pci_fixups_header[];
>  extern struct pci_fixup __start_pci_fixups_final[];
>  extern struct pci_fixup __end_pci_fixups_final[];
> +extern struct pci_fixup __start_pci_fixups_assign[];
> +extern struct pci_fixup __end_pci_fixups_assign[];
>  extern struct pci_fixup __start_pci_fixups_enable[];
>  extern struct pci_fixup __end_pci_fixups_enable[];
>  extern struct pci_fixup __start_pci_fixups_resume[];
> @@ -3405,6 +3407,11 @@ void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev)
>  		end = __end_pci_fixups_final;
>  		break;
>  
> +	case pci_fixup_assign:
> +		start = __start_pci_fixups_assign;
> +		end = __end_pci_fixups_assign;
> +		break;
> +
>  	case pci_fixup_enable:
>  		start = __start_pci_fixups_enable;
>  		end = __end_pci_fixups_enable;
> @@ -4419,3 +4426,21 @@ static void quirk_intel_qat_vf_cap(struct pci_dev *pdev)
>  	}
>  }
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
> +
> +/*
> + * On Mac Pro 11, the allocation of pci bridge memory resource
> + * broke ACPI Sleep Type register region.
> + */
> +static void quirk_mac_disable_mmio_bar(struct pci_dev *dev)
> +{
> +	struct resource *b_res;
> +
> +	dev_info(&dev->dev, "[Quirk] Disable mmio on Mac Pro 11\n");
> +	if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)
> +		return;

Why test for PCI_CLASS_BRIDGE_PCI?  If you do need to test, why is the
test after the dev_info()?

> +	b_res = &dev->resource[PCI_BRIDGE_RESOURCES];
> +	b_res[1].flags = 0;
> +	b_res[2].flags = 0;

You're changing the resource flags but not the hardware itself.  I
assume the window is still enabled and still claims address space, so
we don't want to throw away the information about it, because then we
don't know whether downstream devices can work, and we can't safely
assign resources to peers.

> +}
> +DECLARE_PCI_FIXUP_ASSIGN(PCI_VENDOR_ID_INTEL, 0x8c10, quirk_mac_disable_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.

> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 55641a3..730d6fd 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -1256,6 +1256,8 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct list_head *realloc_head)
>  			additional_io_size  = pci_hotplug_io_size;
>  			additional_mem_size = pci_hotplug_mem_size;
>  		}
> +
> +		pci_fixup_device(pci_fixup_assign, bus->self);
>  		/* Fall through */
>  	default:
>  		pbus_size_io(bus, realloc_head ? 0 : additional_io_size,
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 6a67ab9..3ba05f0 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -283,6 +283,9 @@
>  		VMLINUX_SYMBOL(__start_pci_fixups_final) = .;		\
>  		*(.pci_fixup_final)					\
>  		VMLINUX_SYMBOL(__end_pci_fixups_final) = .;		\
> +		VMLINUX_SYMBOL(__start_pci_fixups_assign) = .;		\
> +		*(.pci_fixup_assign)					\
> +		VMLINUX_SYMBOL(__end_pci_fixups_assign) = .;		\
>  		VMLINUX_SYMBOL(__start_pci_fixups_enable) = .;		\
>  		*(.pci_fixup_enable)					\
>  		VMLINUX_SYMBOL(__end_pci_fixups_enable) = .;		\
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index b67e4df..14a35bb 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1584,6 +1584,7 @@ enum pci_fixup_pass {
>  	pci_fixup_early,	/* Before probing BARs */
>  	pci_fixup_header,	/* After reading configuration header */
>  	pci_fixup_final,	/* Final phase of device fixups */
> +	pci_fixup_assign,	/* Before resource assignment */
>  	pci_fixup_enable,	/* pci_enable_device() time */
>  	pci_fixup_resume,	/* pci_device_resume() */
>  	pci_fixup_suspend,	/* pci_device_suspend() */
> @@ -1644,6 +1645,9 @@ enum pci_fixup_pass {
>  #define DECLARE_PCI_FIXUP_FINAL(vendor, device, hook)			\
>  	DECLARE_PCI_FIXUP_SECTION(.pci_fixup_final,			\
>  		hook, vendor, device, PCI_ANY_ID, 0, hook)
> +#define DECLARE_PCI_FIXUP_ASSIGN(vendor, device, hook)			\
> +	DECLARE_PCI_FIXUP_SECTION(.pci_fixup_assign,			\
> +		hook, vendor, device, PCI_ANY_ID, 0, hook)
>  #define DECLARE_PCI_FIXUP_ENABLE(vendor, device, hook)			\
>  	DECLARE_PCI_FIXUP_SECTION(.pci_fixup_enable,			\
>  		hook, vendor, device, PCI_ANY_ID, 0, hook)
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 48958d3..248acdb 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -877,6 +877,7 @@ static void check_section(const char *modname, struct elf_info *elf,
>  
>  #define ALL_PCI_INIT_SECTIONS	\
>  	".pci_fixup_early", ".pci_fixup_header", ".pci_fixup_final", \
> +	".pci_fixup_assign", \
>  	".pci_fixup_enable", ".pci_fixup_resume", \
>  	".pci_fixup_resume_early", ".pci_fixup_suspend"
>  
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Bjorn Helgaas]

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 registers.
> 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.

> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
> Tested-by: Cedric Le Goater <clg@kaod.org>
> Tested-by: pkozlov <pkozlov.vrn@gmail.com>
> Tested-by: Zach Norman <zach@nor.mn>
> Tested-by: Pablo Catalina <pablo.catalina@gmail.com>
> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> ---
>  drivers/pci/quirks.c              | 25 +++++++++++++++++++++++++
>  drivers/pci/setup-bus.c           |  2 ++
>  include/asm-generic/vmlinux.lds.h |  3 +++
>  include/linux/pci.h               |  4 ++++
>  scripts/mod/modpost.c             |  1 +
>  5 files changed, 35 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index ee72ebe..e347047 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3370,6 +3370,8 @@ extern struct pci_fixup __start_pci_fixups_header[];
>  extern struct pci_fixup __end_pci_fixups_header[];
>  extern struct pci_fixup __start_pci_fixups_final[];
>  extern struct pci_fixup __end_pci_fixups_final[];
> +extern struct pci_fixup __start_pci_fixups_assign[];
> +extern struct pci_fixup __end_pci_fixups_assign[];
>  extern struct pci_fixup __start_pci_fixups_enable[];
>  extern struct pci_fixup __end_pci_fixups_enable[];
>  extern struct pci_fixup __start_pci_fixups_resume[];
> @@ -3405,6 +3407,11 @@ void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev)
>  		end = __end_pci_fixups_final;
>  		break;
>  
> +	case pci_fixup_assign:
> +		start = __start_pci_fixups_assign;
> +		end = __end_pci_fixups_assign;
> +		break;
> +
>  	case pci_fixup_enable:
>  		start = __start_pci_fixups_enable;
>  		end = __end_pci_fixups_enable;
> @@ -4419,3 +4426,21 @@ static void quirk_intel_qat_vf_cap(struct pci_dev *pdev)
>  	}
>  }
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
> +
> +/*
> + * On Mac Pro 11, the allocation of pci bridge memory resource
> + * broke ACPI Sleep Type register region.
> + */
> +static void quirk_mac_disable_mmio_bar(struct pci_dev *dev)
> +{
> +	struct resource *b_res;
> +
> +	dev_info(&dev->dev, "[Quirk] Disable mmio on Mac Pro 11\n");
> +	if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)
> +		return;

Why test for PCI_CLASS_BRIDGE_PCI?  If you do need to test, why is the
test after the dev_info()?

> +	b_res = &dev->resource[PCI_BRIDGE_RESOURCES];
> +	b_res[1].flags = 0;
> +	b_res[2].flags = 0;

You're changing the resource flags but not the hardware itself.  I
assume the window is still enabled and still claims address space, so
we don't want to throw away the information about it, because then we
don't know whether downstream devices can work, and we can't safely
assign resources to peers.

> +}
> +DECLARE_PCI_FIXUP_ASSIGN(PCI_VENDOR_ID_INTEL, 0x8c10, quirk_mac_disable_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.

> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 55641a3..730d6fd 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -1256,6 +1256,8 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct list_head *realloc_head)
>  			additional_io_size  = pci_hotplug_io_size;
>  			additional_mem_size = pci_hotplug_mem_size;
>  		}
> +
> +		pci_fixup_device(pci_fixup_assign, bus->self);
>  		/* Fall through */
>  	default:
>  		pbus_size_io(bus, realloc_head ? 0 : additional_io_size,
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 6a67ab9..3ba05f0 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -283,6 +283,9 @@
>  		VMLINUX_SYMBOL(__start_pci_fixups_final) = .;		\
>  		*(.pci_fixup_final)					\
>  		VMLINUX_SYMBOL(__end_pci_fixups_final) = .;		\
> +		VMLINUX_SYMBOL(__start_pci_fixups_assign) = .;		\
> +		*(.pci_fixup_assign)					\
> +		VMLINUX_SYMBOL(__end_pci_fixups_assign) = .;		\
>  		VMLINUX_SYMBOL(__start_pci_fixups_enable) = .;		\
>  		*(.pci_fixup_enable)					\
>  		VMLINUX_SYMBOL(__end_pci_fixups_enable) = .;		\
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index b67e4df..14a35bb 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1584,6 +1584,7 @@ enum pci_fixup_pass {
>  	pci_fixup_early,	/* Before probing BARs */
>  	pci_fixup_header,	/* After reading configuration header */
>  	pci_fixup_final,	/* Final phase of device fixups */
> +	pci_fixup_assign,	/* Before resource assignment */
>  	pci_fixup_enable,	/* pci_enable_device() time */
>  	pci_fixup_resume,	/* pci_device_resume() */
>  	pci_fixup_suspend,	/* pci_device_suspend() */
> @@ -1644,6 +1645,9 @@ enum pci_fixup_pass {
>  #define DECLARE_PCI_FIXUP_FINAL(vendor, device, hook)			\
>  	DECLARE_PCI_FIXUP_SECTION(.pci_fixup_final,			\
>  		hook, vendor, device, PCI_ANY_ID, 0, hook)
> +#define DECLARE_PCI_FIXUP_ASSIGN(vendor, device, hook)			\
> +	DECLARE_PCI_FIXUP_SECTION(.pci_fixup_assign,			\
> +		hook, vendor, device, PCI_ANY_ID, 0, hook)
>  #define DECLARE_PCI_FIXUP_ENABLE(vendor, device, hook)			\
>  	DECLARE_PCI_FIXUP_SECTION(.pci_fixup_enable,			\
>  		hook, vendor, device, PCI_ANY_ID, 0, hook)
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 48958d3..248acdb 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -877,6 +877,7 @@ static void check_section(const char *modname, struct elf_info *elf,
>  
>  #define ALL_PCI_INIT_SECTIONS	\
>  	".pci_fixup_early", ".pci_fixup_header", ".pci_fixup_final", \
> +	".pci_fixup_assign", \
>  	".pci_fixup_enable", ".pci_fixup_resume", \
>  	".pci_fixup_resume_early", ".pci_fixup_suspend"
>  
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Lukas Wunner]

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 registers.
> > 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_disable_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 the
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=218181

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 all,
put it into D3 and leave it alone.

Best regards,

Lukas

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

[Chen Yu]

Hi Bjorn,

On 2016年05月31日 05:33, 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 registers.
>> 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.
Yes, I don't know the root cause neither, so I send this patch to ask for
help, maybe we should  also invite Apple people in..
>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
>> Tested-by: Cedric Le Goater <clg@kaod.org>
>> Tested-by: pkozlov <pkozlov.vrn@gmail.com>
>> Tested-by: Zach Norman <zach@nor.mn>
>> Tested-by: Pablo Catalina <pablo.catalina@gmail.com>
>> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
>> ---
>>   drivers/pci/quirks.c              | 25 +++++++++++++++++++++++++
>>   drivers/pci/setup-bus.c           |  2 ++
>>   include/asm-generic/vmlinux.lds.h |  3 +++
>>   include/linux/pci.h               |  4 ++++
>>   scripts/mod/modpost.c             |  1 +
>>   5 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index ee72ebe..e347047 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3370,6 +3370,8 @@ extern struct pci_fixup __start_pci_fixups_header[];
>>   extern struct pci_fixup __end_pci_fixups_header[];
>>   extern struct pci_fixup __start_pci_fixups_final[];
>>   extern struct pci_fixup __end_pci_fixups_final[];
>> +extern struct pci_fixup __start_pci_fixups_assign[];
>> +extern struct pci_fixup __end_pci_fixups_assign[];
>>   extern struct pci_fixup __start_pci_fixups_enable[];
>>   extern struct pci_fixup __end_pci_fixups_enable[];
>>   extern struct pci_fixup __start_pci_fixups_resume[];
>> @@ -3405,6 +3407,11 @@ void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev)
>>   		end = __end_pci_fixups_final;
>>   		break;
>>   
>> +	case pci_fixup_assign:
>> +		start = __start_pci_fixups_assign;
>> +		end = __end_pci_fixups_assign;
>> +		break;
>> +
>>   	case pci_fixup_enable:
>>   		start = __start_pci_fixups_enable;
>>   		end = __end_pci_fixups_enable;
>> @@ -4419,3 +4426,21 @@ static void quirk_intel_qat_vf_cap(struct pci_dev *pdev)
>>   	}
>>   }
>>   DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
>> +
>> +/*
>> + * On Mac Pro 11, the allocation of pci bridge memory resource
>> + * broke ACPI Sleep Type register region.
>> + */
>> +static void quirk_mac_disable_mmio_bar(struct pci_dev *dev)
>> +{
>> +	struct resource *b_res;
>> +
>> +	dev_info(&dev->dev, "[Quirk] Disable mmio on Mac Pro 11\n");
>> +	if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)
>> +		return;
> Why test for PCI_CLASS_BRIDGE_PCI?  If you do need to test, why is the
> test after the dev_info()?
This checking is not needed, since we only invoke 
pci_fixup_device(pci_fixup_assign)
for bridges. I can remove it.
>
>> +	b_res = &dev->resource[PCI_BRIDGE_RESOURCES];
>> +	b_res[1].flags = 0;
>> +	b_res[2].flags = 0;
> You're changing the resource flags but not the hardware itself.  I
> assume the window is still enabled and still claims address space, so
> we don't want to throw away the information about it, because then we
> don't know whether downstream devices can work, and we can't safely
> assign resources to peers.
If I understand correctly, according to the boot logs, the pci bridge
in question has not declaimed any valid device/bridge resource
(both io and mem) during  probe(because base=0xfff>limit=0x0),
so I think it has not hardware resource setting at that time(at least
in BIOS)
until it reaches pcibios_assign_resources and it has to allocate a
minimal io/mem resource, then it tries to  assign them to
[mem 0x7fa00000 - 0x7fbfffff]
[mem 0x7fc00000-0x7fdfffff 64bit pref]
[io 0x2000-0x2fff],
so if we reset the flag to zero for these mem resource, the pci bridge
  will not assign any pci mem windows for it
(in this way
find_free_bus_resource(bus, mask | IORESOURCE_PREFETCH, type)
will not return any free resource, thus bypass the assignment)

According to the boot log at 
https://bugzilla.kernel.org/attachment.cgi?id=210141
,  we can see there is no bridge windows assign for 0000:00:1c.0 during 
early probe:

[    0.807893] pci 0000:00:1c.0: [8086:8c10] type 01 class 0x060400
[    0.807949] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    0.831281] pci 0000:00:1c.0: PCI bridge to [bus 02]

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

>
>> +}
>> +DECLARE_PCI_FIXUP_ASSIGN(PCI_VENDOR_ID_INTEL, 0x8c10, quirk_mac_disable_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.
Maybe not only used for Mac Pro 11, so should it be a dmi match+pci quirk?

thanks,
Yu

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

[Chen Yu]

Hi Lukas,

On 2016年05月31日 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 registers.
>>> 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_disable_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 the
> 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=218181
>
> 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 all,
> 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=216661
, but it looks like although poweroff works however
the wifi and facetime are broken:
https://bugzilla.kernel.org/show_bug.cgi?id=103211#c109

Thanks,
Yu

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

[Yinghai Lu]

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.

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

[Chen Yu]

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.

thanks,
Yu

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

[Chen Yu]

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.

thanks,
Yu

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

[Bjorn Helgaas]

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.

Bjorn

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

[Bjorn Helgaas]

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.

Bjorn

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

[Chen Yu]

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

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

[Chen Yu]

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

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

[Bjorn Helgaas]

On Wed, Jun 08, 2016 at 12:31:27PM +0800, Chen Yu wrote:
> 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?

This is not a root cause.  We still have no idea why the problem
occurs.  I do not think a quirk is a good idea until we know what the
problem is and exactly how a quirk would fix it.

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

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

[Bjorn Helgaas]

On Wed, Jun 08, 2016 at 07:47:42AM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 08, 2016 at 12:31:27PM +0800, Chen Yu wrote:
> > 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?
> 
> This is not a root cause.  We still have no idea why the problem
> occurs.  I do not think a quirk is a good idea until we know what the
> problem is and exactly how a quirk would fix it.
> 
> > lspci result from Mac OS, there's no resource behind this bridge:
> > https://bugzilla.kernel.org/attachment.cgi?id=219321

Here are some ideas for debugging this:

1) Apparently the problem is sensitive to programming the prefetchable
   memory aperture of 00:1c.0 to [mem 0x7fc00000-0x7fdfffff 64bit
   pref].  The only effect of that *should* be that the bridge will
   now claim accesses in the aperture, when it didn't before.

   We *think* there's nothing else at the address of that aperture,
   but if there is an unreported device there, it may stop working.  I
   would pore over the E820 memory map, EFI memory map, all ACPI _CRS
   methods, etc., looking for anything in that area that we haven't
   accounted for.

   There are lots of anomalies in this system, e.g., (these are from
   Bastien's dmesg log at
   https://bugzilla.kernel.org/attachment.cgi?id=208961)

     BIOS-e820: [mem 0x00000000e00f8000-0x00000000e00f8fff] reserved
     PCI: MMCONFIG for domain 0000 [bus 00-9b] at [mem 0xe0000000-0xe9bfffff] (base 0xe0000000)
     acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-9b] only partially covers this bridge
     pci_bus 0000:00: root bus resource [mem 0x7fa00000-0xfeafffff window]
     system 00:04: [mem 0xe0000000-0xefffffff] could not be reserved
     ACPI Warning: SystemIO range 0x000000000000EFA0-0x000000000000EFBF conflicts with OpRegion 0x000000000000EFA0-0x000000000000EFAF (\_SB.PCI0.SBUS.SMBI)

   The MMCONFIG area appears correctly described in the 00:04 _CRS,
   but incorrectly in MCFG.  The E820 region appears to be a chunk in
   the middle of the MMCONFIG area.  The host bridge window 
   [mem 0x7fa00000-0xfeafffff window] is clearly bogus -- it includes
   the MMCONFIG area, which is definitely not a window.  I doubt
   anything above 0xdfffffff should be included.

   I don't know what the ACPI conflict warning is about, but I'd try
   to figure it out.

   Either the firmware is badly broken, or we're not interpreting
   something correctly.

   I'd try assigning the 00:1c.0 aperture at the end of the actual
   aperture instead of the beginning.  I think Windows, and likely
   MacOS uses a top-down allocation strategy instead of bottom-up like
   Linux does.  If that makes poweroff work, there is likely an
   unreported device in the [mem 0x7fc00000-0x7fdfffff 64bit pref]
   area.

   This experimentation could all be done with setpci, without
   requiring kernel patches.

2) I would explore exactly what the grub "halt" command does and how
   it compares to what Linux is doing.  I see the assertion that this
   is related to [io 0x1804], but I don't know what that's based on.
   Programming the 00:1c.0 prefetchable aperture shouldn't have
   anything to do with I/O ports, so if it really is related, there
   might be some SMM magic or something where SMM code is doing
   something that relates to the memory aperture.

3) The lspci output at https://bugzilla.kernel.org/attachment.cgi?id=219321
   (I think this is from MacOS) shows invalid data for devices
   starting at 04:00.0.  Why?  Maybe this is an unrelated artifact,
   but it doesn't smell right.

4) If you can hot-add devices under MacOS, look to see what address
   space they get assigned.  That may tell you what allocation
   strategy MacOS uses.

5) 00:1c.0 claims to have a slot that supports hotplug.  Is that
   actually true?  Could you add a device below it?  If not, maybe the
   problem is that the BIOS should have configured 00:1c.0 so it
   doesn't report a slot.  If it didn't report a slot, we shouldn't
   assign resources to it, since there is no possibility of a device
   below it.

Bjorn

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

[Bjorn Helgaas]

On Wed, Jun 08, 2016 at 07:47:42AM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 08, 2016 at 12:31:27PM +0800, Chen Yu wrote:
> > 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?
> 
> This is not a root cause.  We still have no idea why the problem
> occurs.  I do not think a quirk is a good idea until we know what the
> problem is and exactly how a quirk would fix it.
> 
> > lspci result from Mac OS, there's no resource behind this bridge:
> > https://bugzilla.kernel.org/attachment.cgi?id=219321

Here are some ideas for debugging this:

1) Apparently the problem is sensitive to programming the prefetchable
   memory aperture of 00:1c.0 to [mem 0x7fc00000-0x7fdfffff 64bit
   pref].  The only effect of that *should* be that the bridge will
   now claim accesses in the aperture, when it didn't before.

   We *think* there's nothing else at the address of that aperture,
   but if there is an unreported device there, it may stop working.  I
   would pore over the E820 memory map, EFI memory map, all ACPI _CRS
   methods, etc., looking for anything in that area that we haven't
   accounted for.

   There are lots of anomalies in this system, e.g., (these are from
   Bastien's dmesg log at
   https://bugzilla.kernel.org/attachment.cgi?id=208961)

     BIOS-e820: [mem 0x00000000e00f8000-0x00000000e00f8fff] reserved
     PCI: MMCONFIG for domain 0000 [bus 00-9b] at [mem 0xe0000000-0xe9bfffff] (base 0xe0000000)
     acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-9b] only partially covers this bridge
     pci_bus 0000:00: root bus resource [mem 0x7fa00000-0xfeafffff window]
     system 00:04: [mem 0xe0000000-0xefffffff] could not be reserved
     ACPI Warning: SystemIO range 0x000000000000EFA0-0x000000000000EFBF conflicts with OpRegion 0x000000000000EFA0-0x000000000000EFAF (\_SB.PCI0.SBUS.SMBI)

   The MMCONFIG area appears correctly described in the 00:04 _CRS,
   but incorrectly in MCFG.  The E820 region appears to be a chunk in
   the middle of the MMCONFIG area.  The host bridge window 
   [mem 0x7fa00000-0xfeafffff window] is clearly bogus -- it includes
   the MMCONFIG area, which is definitely not a window.  I doubt
   anything above 0xdfffffff should be included.

   I don't know what the ACPI conflict warning is about, but I'd try
   to figure it out.

   Either the firmware is badly broken, or we're not interpreting
   something correctly.

   I'd try assigning the 00:1c.0 aperture at the end of the actual
   aperture instead of the beginning.  I think Windows, and likely
   MacOS uses a top-down allocation strategy instead of bottom-up like
   Linux does.  If that makes poweroff work, there is likely an
   unreported device in the [mem 0x7fc00000-0x7fdfffff 64bit pref]
   area.

   This experimentation could all be done with setpci, without
   requiring kernel patches.

2) I would explore exactly what the grub "halt" command does and how
   it compares to what Linux is doing.  I see the assertion that this
   is related to [io 0x1804], but I don't know what that's based on.
   Programming the 00:1c.0 prefetchable aperture shouldn't have
   anything to do with I/O ports, so if it really is related, there
   might be some SMM magic or something where SMM code is doing
   something that relates to the memory aperture.

3) The lspci output at https://bugzilla.kernel.org/attachment.cgi?id=219321
   (I think this is from MacOS) shows invalid data for devices
   starting at 04:00.0.  Why?  Maybe this is an unrelated artifact,
   but it doesn't smell right.

4) If you can hot-add devices under MacOS, look to see what address
   space they get assigned.  That may tell you what allocation
   strategy MacOS uses.

5) 00:1c.0 claims to have a slot that supports hotplug.  Is that
   actually true?  Could you add a device below it?  If not, maybe the
   problem is that the BIOS should have configured 00:1c.0 so it
   doesn't report a slot.  If it didn't report a slot, we shouldn't
   assign resources to it, since there is no possibility of a device
   below it.

Bjorn

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

[Bjorn Helgaas]

On Thu, Jun 09, 2016 at 11:50:11AM -0500, Bjorn Helgaas wrote:

> 5) 00:1c.0 claims to have a slot that supports hotplug.  Is that
>    actually true?  Could you add a device below it?  If not, maybe the
>    problem is that the BIOS should have configured 00:1c.0 so it
>    doesn't report a slot.  If it didn't report a slot, we shouldn't
>    assign resources to it, since there is no possibility of a device
>    below it.

Of course, this would only be *part* of the problem, because a hot-added
device somewhere else could still be assigned the space at 
[mem 0x7fc00000-0x7fdfffff].

This just smells like an unreported device in there somewhere.

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

[Bjorn Helgaas]

On Thu, Jun 09, 2016 at 11:50:11AM -0500, Bjorn Helgaas wrote:

> 5) 00:1c.0 claims to have a slot that supports hotplug.  Is that
>    actually true?  Could you add a device below it?  If not, maybe the
>    problem is that the BIOS should have configured 00:1c.0 so it
>    doesn't report a slot.  If it didn't report a slot, we shouldn't
>    assign resources to it, since there is no possibility of a device
>    below it.

Of course, this would only be *part* of the problem, because a hot-added
device somewhere else could still be assigned the space at 
[mem 0x7fc00000-0x7fdfffff].

This just smells like an unreported device in there somewhere.