--- /dev/null
+From 622532bb2fad8fe342fb685727ae0be566f6be5d Mon Sep 17 00:00:00 2001
+From: Witold Szczeponik <Witold.Szczeponik@gmx.net>
+Date: Fri, 1 May 2015 19:05:20 +0200
+Subject: ACPI / PNP: add two IDs to list for PNPACPI device enumeration
+
+From: Witold Szczeponik <Witold.Szczeponik@gmx.net>
+
+commit 622532bb2fad8fe342fb685727ae0be566f6be5d upstream.
+
+Commit eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device
+enumeration) changed the way how ACPI devices are enumerated and when
+they are added to the PNP bus.
+
+However, it broke the sound card support on (at least) a vintage
+IBM ThinkPad 600E: with said commit applied, two of the necessary
+"CSC01xx" devices are not added to the PNP bus and hence can not be
+found during the initialization of the "snd-cs4236" module. As a
+consequence, loading "snd-cs4236" causes null pointer exceptions.
+The attached patch fixes the problem end re-enables sound on the
+IBM ThinkPad 600E.
+
+Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
+Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/acpi_pnp.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/acpi/acpi_pnp.c
++++ b/drivers/acpi/acpi_pnp.c
+@@ -304,6 +304,8 @@ static const struct acpi_device_id acpi_
+ {"PNPb006"},
+ /* cs423x-pnpbios */
+ {"CSC0100"},
++ {"CSC0103"},
++ {"CSC0110"},
+ {"CSC0000"},
+ {"GIM0100"}, /* Guillemot Turtlebeach something appears to be cs4232 compatible */
+ /* es18xx-pnpbios */
--- /dev/null
+From 3349fb64b2927407017d970dd5c4daf3c5ad69f8 Mon Sep 17 00:00:00 2001
+From: Chris Bainbridge <chris.bainbridge@gmail.com>
+Date: Wed, 29 Apr 2015 21:21:40 +0100
+Subject: ACPI / SBS: Add 5 us delay to fix SBS hangs on MacBook
+
+From: Chris Bainbridge <chris.bainbridge@gmail.com>
+
+commit 3349fb64b2927407017d970dd5c4daf3c5ad69f8 upstream.
+
+Commit 7bc5a2bad0b8 'ACPI: Support _OSI("Darwin") correctly' caused
+the MacBook firmware to expose the SBS, resulting in intermittent
+hangs of several minutes on boot, and failure to detect or report
+the battery. Fix this by adding a 5 us delay to the start of each
+SMBUS transaction. This timing is the result of experimentation -
+hangs were observed with 3 us but never with 5 us.
+
+Fixes: 7bc5a2bad0b8 'ACPI: Support _OSI("Darwin") correctly'
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=94651
+Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
+Cc: 3.18+ <stable@vger.kernel.org> # 3.18+
+[ rjw: Subject and changelog ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/sbshc.c | 22 ++++++++++++++++++++++
+ 1 file changed, 22 insertions(+)
+
+--- a/drivers/acpi/sbshc.c
++++ b/drivers/acpi/sbshc.c
+@@ -14,6 +14,7 @@
+ #include <linux/delay.h>
+ #include <linux/module.h>
+ #include <linux/interrupt.h>
++#include <linux/dmi.h>
+ #include "sbshc.h"
+
+ #define PREFIX "ACPI: "
+@@ -87,6 +88,8 @@ enum acpi_smb_offset {
+ ACPI_SMB_ALARM_DATA = 0x26, /* 2 bytes alarm data */
+ };
+
++static bool macbook;
++
+ static inline int smb_hc_read(struct acpi_smb_hc *hc, u8 address, u8 *data)
+ {
+ return ec_read(hc->offset + address, data);
+@@ -132,6 +135,8 @@ static int acpi_smbus_transaction(struct
+ }
+
+ mutex_lock(&hc->lock);
++ if (macbook)
++ udelay(5);
+ if (smb_hc_read(hc, ACPI_SMB_PROTOCOL, &temp))
+ goto end;
+ if (temp) {
+@@ -257,12 +262,29 @@ extern int acpi_ec_add_query_handler(str
+ acpi_handle handle, acpi_ec_query_func func,
+ void *data);
+
++static int macbook_dmi_match(const struct dmi_system_id *d)
++{
++ pr_debug("Detected MacBook, enabling workaround\n");
++ macbook = true;
++ return 0;
++}
++
++static struct dmi_system_id acpi_smbus_dmi_table[] = {
++ { macbook_dmi_match, "Apple MacBook", {
++ DMI_MATCH(DMI_BOARD_VENDOR, "Apple"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "MacBook") },
++ },
++ { },
++};
++
+ static int acpi_smbus_hc_add(struct acpi_device *device)
+ {
+ int status;
+ unsigned long long val;
+ struct acpi_smb_hc *hc;
+
++ dmi_check_system(acpi_smbus_dmi_table);
++
+ if (!device)
+ return -EINVAL;
+
--- /dev/null
+x86-spinlocks-fix-regression-in-spinlock-contention-detection.patch
+acpi-sbs-add-5-us-delay-to-fix-sbs-hangs-on-macbook.patch
+x86-pci-acpi-make-all-resources-except-available-on-pci-bus.patch
+acpi-pnp-add-two-ids-to-list-for-pnpacpi-device-enumeration.patch
--- /dev/null
+From 2c62e8492ed7358bbe7da51666c7e0f6da9474ee Mon Sep 17 00:00:00 2001
+From: Jiang Liu <jiang.liu@linux.intel.com>
+Date: Thu, 30 Apr 2015 12:41:28 +0800
+Subject: x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff] available on PCI bus
+
+From: Jiang Liu <jiang.liu@linux.intel.com>
+
+commit 2c62e8492ed7358bbe7da51666c7e0f6da9474ee upstream.
+
+An IO port or MMIO resource assigned to a PCI host bridge may be
+consumed by the host bridge itself or available to its child
+bus/devices. The ACPI specification defines a bit (Producer/Consumer)
+to tell whether the resource is consumed by the host bridge itself,
+but firmware hasn't used that bit consistently, so we can't rely on it.
+
+Before commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource
+interfaces to simplify implementation"), arch/x86/pci/acpi.c ignored
+all IO port resources defined by acpi_resource_io and
+acpi_resource_fixed_io to filter out IO ports consumed by the host
+bridge itself.
+
+Commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces
+to simplify implementation") started accepting all IO port and MMIO
+resources, which caused a regression that IO port resources consumed
+by the host bridge itself became available to its child devices.
+
+Then commit 63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
+host bridge itself") ignored resources consumed by the host bridge
+itself by checking the IORESOURCE_WINDOW flag, which accidently removed
+MMIO resources defined by acpi_resource_memory24, acpi_resource_memory32
+and acpi_resource_fixed_memory32.
+
+On x86 and IA64 platforms, all IO port and MMIO resources are assumed
+to be available to child bus/devices except one special case:
+ IO port [0xCF8-0xCFF] is consumed by the host bridge itself
+ to access PCI configuration space.
+
+So explicitly filter out PCI CFG IO ports[0xCF8-0xCFF]. This solution
+will also ease the way to consolidate ACPI PCI host bridge common code
+from x86, ia64 and ARM64.
+
+Related ACPI table are archived at:
+https://bugzilla.kernel.org/show_bug.cgi?id=94221
+
+Related discussions at:
+http://patchwork.ozlabs.org/patch/461633/
+https://lkml.org/lkml/2015/3/29/304
+
+Fixes: 63f1789ec716 (Ignore resources consumed by host bridge itself)
+Reported-by: Bernhard Thaler <bernhard.thaler@wvnet.at>
+Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
+Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/pci/acpi.c | 24 ++++++++++++++++++++++--
+ drivers/acpi/resource.c | 2 +-
+ 2 files changed, 23 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/pci/acpi.c
++++ b/arch/x86/pci/acpi.c
+@@ -325,6 +325,26 @@ static void release_pci_root_info(struct
+ kfree(info);
+ }
+
++/*
++ * An IO port or MMIO resource assigned to a PCI host bridge may be
++ * consumed by the host bridge itself or available to its child
++ * bus/devices. The ACPI specification defines a bit (Producer/Consumer)
++ * to tell whether the resource is consumed by the host bridge itself,
++ * but firmware hasn't used that bit consistently, so we can't rely on it.
++ *
++ * On x86 and IA64 platforms, all IO port and MMIO resources are assumed
++ * to be available to child bus/devices except one special case:
++ * IO port [0xCF8-0xCFF] is consumed by the host bridge itself
++ * to access PCI configuration space.
++ *
++ * So explicitly filter out PCI CFG IO ports[0xCF8-0xCFF].
++ */
++static bool resource_is_pcicfg_ioport(struct resource *res)
++{
++ return (res->flags & IORESOURCE_IO) &&
++ res->start == 0xCF8 && res->end == 0xCFF;
++}
++
+ static void probe_pci_root_info(struct pci_root_info *info,
+ struct acpi_device *device,
+ int busnum, int domain,
+@@ -346,8 +366,8 @@ static void probe_pci_root_info(struct p
+ "no IO and memory resources present in _CRS\n");
+ else
+ resource_list_for_each_entry_safe(entry, tmp, list) {
+- if ((entry->res->flags & IORESOURCE_WINDOW) == 0 ||
+- (entry->res->flags & IORESOURCE_DISABLED))
++ if ((entry->res->flags & IORESOURCE_DISABLED) ||
++ resource_is_pcicfg_ioport(entry->res))
+ resource_list_destroy_entry(entry);
+ else
+ entry->res->name = info->name;
+--- a/drivers/acpi/resource.c
++++ b/drivers/acpi/resource.c
+@@ -573,7 +573,7 @@ EXPORT_SYMBOL_GPL(acpi_dev_get_resources
+ * @ares: Input ACPI resource object.
+ * @types: Valid resource types of IORESOURCE_XXX
+ *
+- * This is a hepler function to support acpi_dev_get_resources(), which filters
++ * This is a helper function to support acpi_dev_get_resources(), which filters
+ * ACPI resource objects according to resource types.
+ */
+ int acpi_dev_filter_resource_type(struct acpi_resource *ares,
--- /dev/null
+From e8a4a2696fecb398b0288c43c0e0dbb91e265bb2 Mon Sep 17 00:00:00 2001
+From: Tahsin Erdogan <tahsin@google.com>
+Date: Mon, 4 May 2015 21:15:31 -0700
+Subject: x86/spinlocks: Fix regression in spinlock contention detection
+
+From: Tahsin Erdogan <tahsin@google.com>
+
+commit e8a4a2696fecb398b0288c43c0e0dbb91e265bb2 upstream.
+
+A spinlock is regarded as contended when there is at least one waiter.
+Currently, the code that checks whether there are any waiters rely on
+tail value being greater than head. However, this is not true if tail
+reaches the max value and wraps back to zero, so arch_spin_is_contended()
+incorrectly returns 0 (not contended) when tail is smaller than head.
+
+The original code (before regression) handled this case by casting the
+(tail - head) to an unsigned value. This change simply restores that
+behavior.
+
+Fixes: d6abfdb20223 ("x86/spinlocks/paravirt: Fix memory corruption on unlock")
+Signed-off-by: Tahsin Erdogan <tahsin@google.com>
+Cc: peterz@infradead.org
+Cc: Waiman.Long@hp.com
+Cc: borntraeger@de.ibm.com
+Cc: oleg@redhat.com
+Cc: raghavendra.kt@linux.vnet.ibm.com
+Link: http://lkml.kernel.org/r/1430799331-20445-1-git-send-email-tahsin@google.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/spinlock.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/include/asm/spinlock.h
++++ b/arch/x86/include/asm/spinlock.h
+@@ -169,7 +169,7 @@ static inline int arch_spin_is_contended
+ struct __raw_tickets tmp = READ_ONCE(lock->tickets);
+
+ tmp.head &= ~TICKET_SLOWPATH_FLAG;
+- return (tmp.tail - tmp.head) > TICKET_LOCK_INC;
++ return (__ticket_t)(tmp.tail - tmp.head) > TICKET_LOCK_INC;
+ }
+ #define arch_spin_is_contended arch_spin_is_contended
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
