From cb171f7abb9a1a250fb41d088b81799f75bd1357 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 23 Apr 2014 10:21:06 -0600 Subject: PNP: Work around BIOS defects in Intel MCH area reporting Work around BIOSes that don't report the entire Intel MCH area. MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a PNP0C02 resource. The MCH space was once 16KB, but is 32KB in newer parts. Some BIOSes still report a PNP0C02 resource that is only 16KB, which means the rest of the MCH space is consumed but unreported. This can cause resource map sanity check warnings or (theoretically) a device conflict if we assigned the unreported space to another device. The Intel perf event uncore driver tripped over this when it claimed the MCH region: resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 Info: mapping multiple BARs. Your kernel is fine. To prevent this, if we find a PNP0C02 resource that covers part of the MCH space, extend it to cover the entire space. References: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic Reported-and-tested-by: Borislav Petkov Signed-off-by: Bjorn Helgaas Acked-by: Borislav Petkov Acked-by: Stephane Eranian Signed-off-by: Rafael J. Wysocki --- drivers/pnp/quirks.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/drivers/pnp/quirks.c b/drivers/pnp/quirks.c index 258fef272ea7..3736bc408adb 100644 --- a/drivers/pnp/quirks.c +++ b/drivers/pnp/quirks.c @@ -15,6 +15,7 @@ #include #include +#include #include #include #include @@ -334,6 +335,81 @@ static void quirk_amd_mmconfig_area(struct pnp_dev *dev) } #endif +#ifdef CONFIG_X86 +/* Device IDs of parts that have 32KB MCH space */ +static const unsigned int mch_quirk_devices[] = { + 0x0154, /* Ivy Bridge */ + 0x0c00, /* Haswell */ +}; + +static struct pci_dev *get_intel_host(void) +{ + int i; + struct pci_dev *host; + + for (i = 0; i < ARRAY_SIZE(mch_quirk_devices); i++) { + host = pci_get_device(PCI_VENDOR_ID_INTEL, mch_quirk_devices[i], + NULL); + if (host) + return host; + } + return NULL; +} + +static void quirk_intel_mch(struct pnp_dev *dev) +{ + struct pci_dev *host; + u32 addr_lo, addr_hi; + struct pci_bus_region region; + struct resource mch; + struct pnp_resource *pnp_res; + struct resource *res; + + host = get_intel_host(); + if (!host) + return; + + /* + * MCHBAR is not an architected PCI BAR, so MCH space is usually + * reported as a PNP0C02 resource. The MCH space was originally + * 16KB, but is 32KB in newer parts. Some BIOSes still report a + * PNP0C02 resource that is only 16KB, which means the rest of the + * MCH space is consumed but unreported. + */ + + /* + * Read MCHBAR for Host Member Mapped Register Range Base + * https://www-ssl.intel.com/content/www/us/en/processors/core/4th-gen-core-family-desktop-vol-2-datasheet + * Sec 3.1.12. + */ + pci_read_config_dword(host, 0x48, &addr_lo); + region.start = addr_lo & ~0x7fff; + pci_read_config_dword(host, 0x4c, &addr_hi); + region.start |= (u64) addr_hi << 32; + region.end = region.start + 32*1024 - 1; + + memset(&mch, 0, sizeof(mch)); + mch.flags = IORESOURCE_MEM; + pcibios_bus_to_resource(host->bus, &mch, ®ion); + + list_for_each_entry(pnp_res, &dev->resources, list) { + res = &pnp_res->res; + if (res->end < mch.start || res->start > mch.end) + continue; /* no overlap */ + if (res->start == mch.start && res->end == mch.end) + continue; /* exact match */ + + dev_info(&dev->dev, FW_BUG "PNP resource %pR covers only part of %s Intel MCH; extending to %pR\n", + res, pci_name(host), &mch); + res->start = mch.start; + res->end = mch.end; + break; + } + + pci_dev_put(host); +} +#endif + /* * PnP Quirks * Cards or devices that need some tweaking due to incomplete resource info @@ -363,6 +439,9 @@ static struct pnp_fixup pnp_fixups[] = { {"PNP0c02", quirk_system_pci_resources}, #ifdef CONFIG_AMD_NB {"PNP0c01", quirk_amd_mmconfig_area}, +#endif +#ifdef CONFIG_X86 + {"PNP0c02", quirk_intel_mch}, #endif {""} }; -- cgit v1.2.3 From f66abe92ce498672ac44d550f51a526597c731c4 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 24 Apr 2014 19:27:49 +0200 Subject: ACPI / notify: Do not block unknown type notifications in root handler MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit 1a699476e258 "ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify()" changed the root notify handler, acpi_bus_notify(), to block unknown type norifications, but it overlooked the fact that they might be propagated to drivers via the ->notify() callback. Fix the problem by allowing drivers to receive unknown type notifications via ->notify() as before. Fixes: 1a699476e258 (ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify()) Reported-and-tested-by: Mantas Mikulėnas Reported-and-tested-by: Sitsofe Wheeler Signed-off-by: Rafael J. Wysocki --- drivers/acpi/bus.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index e7e5844c87d0..cf925c4f36b7 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -380,9 +380,8 @@ static void acpi_bus_notify(acpi_handle handle, u32 type, void *data) break; default: - acpi_handle_warn(handle, "Unsupported event type 0x%x\n", type); - ost_code = ACPI_OST_SC_UNRECOGNIZED_NOTIFY; - goto err; + acpi_handle_debug(handle, "Unknown event type 0x%x\n", type); + break; } adev = acpi_bus_get_acpi_device(handle); -- cgit v1.2.3