--- /dev/null
+From b355cee88e3b1a193f0e9a81db810f6f83ad728b Mon Sep 17 00:00:00 2001
+From: Zhang Rui <rui.zhang@intel.com>
+Date: Thu, 27 Feb 2014 11:37:15 +0800
+Subject: ACPI / resources: ignore invalid ACPI device resources
+
+From: Zhang Rui <rui.zhang@intel.com>
+
+commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream.
+
+ACPI table may export resource entry with 0 length.
+But the current code interprets this kind of resource in a wrong way.
+It will create a resource structure with
+res->end = acpi_resource->start + acpi_resource->len - 1;
+
+This patch fixes a problem on my machine that a platform device fails
+to be created because one of its ACPI IO resource entry (start = 0,
+end = 0, length = 0) is translated into a generic resource with
+start = 0, end = 0xffffffff.
+
+Signed-off-by: Zhang Rui <rui.zhang@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/resource.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/acpi/resource.c
++++ b/drivers/acpi/resource.c
+@@ -77,18 +77,24 @@ bool acpi_dev_resource_memory(struct acp
+ switch (ares->type) {
+ case ACPI_RESOURCE_TYPE_MEMORY24:
+ memory24 = &ares->data.memory24;
++ if (!memory24->address_length)
++ return false;
+ acpi_dev_get_memresource(res, memory24->minimum,
+ memory24->address_length,
+ memory24->write_protect);
+ break;
+ case ACPI_RESOURCE_TYPE_MEMORY32:
+ memory32 = &ares->data.memory32;
++ if (!memory32->address_length)
++ return false;
+ acpi_dev_get_memresource(res, memory32->minimum,
+ memory32->address_length,
+ memory32->write_protect);
+ break;
+ case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+ fixed_memory32 = &ares->data.fixed_memory32;
++ if (!fixed_memory32->address_length)
++ return false;
+ acpi_dev_get_memresource(res, fixed_memory32->address,
+ fixed_memory32->address_length,
+ fixed_memory32->write_protect);
+@@ -144,12 +150,16 @@ bool acpi_dev_resource_io(struct acpi_re
+ switch (ares->type) {
+ case ACPI_RESOURCE_TYPE_IO:
+ io = &ares->data.io;
++ if (!io->address_length)
++ return false;
+ acpi_dev_get_ioresource(res, io->minimum,
+ io->address_length,
+ io->io_decode);
+ break;
+ case ACPI_RESOURCE_TYPE_FIXED_IO:
+ fixed_io = &ares->data.fixed_io;
++ if (!fixed_io->address_length)
++ return false;
+ acpi_dev_get_ioresource(res, fixed_io->address,
+ fixed_io->address_length,
+ ACPI_DECODE_10);
--- /dev/null
+From 052450fdc55894a39fbae93d9bbe43947956f663 Mon Sep 17 00:00:00 2001
+From: Linus Walleij <linus.walleij@linaro.org>
+Date: Tue, 25 Feb 2014 22:41:41 +0100
+Subject: ARM: 7991/1: sa1100: fix compile problem on Collie
+
+From: Linus Walleij <linus.walleij@linaro.org>
+
+commit 052450fdc55894a39fbae93d9bbe43947956f663 upstream.
+
+Due to a problem in the MFD Kconfig it was not possible to
+compile the UCB battery driver for the Collie SA1100 system,
+in turn making it impossible to compile in the battery driver.
+(See patch "mfd: include all drivers in subsystem menu".)
+
+After fixing the MFD Kconfig (separate patch) a compile error
+appears in the Collie battery driver due to the <mach/collie.h>
+implicitly requiring <mach/hardware.h> through <linux/gpio.h>
+via <mach/gpio.h> prior to commit
+40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface".
+
+Fix this up by including the required header into
+<mach/collie.h>.
+
+Cc: Andrea Adami <andrea.adami@gmail.com>
+Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-sa1100/include/mach/collie.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm/mach-sa1100/include/mach/collie.h
++++ b/arch/arm/mach-sa1100/include/mach/collie.h
+@@ -13,6 +13,8 @@
+ #ifndef __ASM_ARCH_COLLIE_H
+ #define __ASM_ARCH_COLLIE_H
+
++#include "hardware.h" /* Gives GPIO_MAX */
++
+ extern void locomolcd_power(int on);
+
+ #define COLLIE_SCOOP_GPIO_BASE (GPIO_MAX + 1)
--- /dev/null
+From 99afb0fd5f05aac467ffa85c36778fec4396209b Mon Sep 17 00:00:00 2001
+From: Li Zefan <lizefan@huawei.com>
+Date: Thu, 27 Feb 2014 18:19:36 +0800
+Subject: cpuset: fix a race condition in __cpuset_node_allowed_softwall()
+
+From: Li Zefan <lizefan@huawei.com>
+
+commit 99afb0fd5f05aac467ffa85c36778fec4396209b upstream.
+
+It's not safe to access task's cpuset after releasing task_lock().
+Holding callback_mutex won't help.
+
+Signed-off-by: Li Zefan <lizefan@huawei.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/cpuset.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/cpuset.c
++++ b/kernel/cpuset.c
+@@ -2422,9 +2422,9 @@ int __cpuset_node_allowed_softwall(int n
+
+ task_lock(current);
+ cs = nearest_hardwall_ancestor(task_cs(current));
++ allowed = node_isset(node, cs->mems_allowed);
+ task_unlock(current);
+
+- allowed = node_isset(node, cs->mems_allowed);
+ mutex_unlock(&callback_mutex);
+ return allowed;
+ }
--- /dev/null
+From c685689fd24d310343ac33942e9a54a974ae9c43 Mon Sep 17 00:00:00 2001
+From: Chuansheng Liu <chuansheng.liu@intel.com>
+Date: Mon, 24 Feb 2014 11:29:50 +0800
+Subject: genirq: Remove racy waitqueue_active check
+
+From: Chuansheng Liu <chuansheng.liu@intel.com>
+
+commit c685689fd24d310343ac33942e9a54a974ae9c43 upstream.
+
+We hit one rare case below:
+
+T1 calling disable_irq(), but hanging at synchronize_irq()
+always;
+The corresponding irq thread is in sleeping state;
+And all CPUs are in idle state;
+
+After analysis, we found there is one possible scenerio which
+causes T1 is waiting there forever:
+CPU0 CPU1
+ synchronize_irq()
+ wait_event()
+ spin_lock()
+ atomic_dec_and_test(&threads_active)
+ insert the __wait into queue
+ spin_unlock()
+ if(waitqueue_active)
+ atomic_read(&threads_active)
+ wake_up()
+
+Here after inserted the __wait into queue on CPU0, and before
+test if queue is empty on CPU1, there is no barrier, it maybe
+cause it is not visible for CPU1 immediately, although CPU0 has
+updated the queue list.
+It is similar for CPU0 atomic_read() threads_active also.
+
+So we'd need one smp_mb() before waitqueue_active.that, but removing
+the waitqueue_active() check solves it as wel l and it makes
+things simple and clear.
+
+Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
+Cc: Xiaoming Wang <xiaoming.wang@intel.com>
+Link: http://lkml.kernel.org/r/1393212590-32543-1-git-send-email-chuansheng.liu@intel.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/irq/manage.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/kernel/irq/manage.c
++++ b/kernel/irq/manage.c
+@@ -802,8 +802,7 @@ static irqreturn_t irq_thread_fn(struct
+
+ static void wake_threads_waitq(struct irq_desc *desc)
+ {
+- if (atomic_dec_and_test(&desc->threads_active) &&
+- waitqueue_active(&desc->wait_for_threads))
++ if (atomic_dec_and_test(&desc->threads_active))
+ wake_up(&desc->wait_for_threads);
+ }
+
--- /dev/null
+From 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b Mon Sep 17 00:00:00 2001
+From: Markus Pargmann <mpa@pengutronix.de>
+Date: Thu, 20 Feb 2014 17:36:03 +0100
+Subject: regulator: core: Replace direct ops->enable usage
+
+From: Markus Pargmann <mpa@pengutronix.de>
+
+commit 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b upstream.
+
+There are some direct ops->enable in the regulator core driver. This is
+a potential issue as the function _regulator_do_enable() handles gpio
+regulators and the normal ops->enable calls. These gpio regulators are
+simply ignored when ops->enable is called directly.
+
+One possible bug is that boot-on and always-on gpio regulators are not
+enabled on registration.
+
+This patch replaces all ops->enable calls by _regulator_do_enable.
+
+[Handle missing enable operations -- broonie]
+
+Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
+Signed-off-by: Mark Brown <broonie@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ drivers/regulator/core.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/regulator/core.c
++++ b/drivers/regulator/core.c
+@@ -919,6 +919,8 @@ static int machine_constraints_voltage(s
+ return 0;
+ }
+
++static int _regulator_do_enable(struct regulator_dev *rdev);
++
+ /**
+ * set_machine_constraints - sets regulator constraints
+ * @rdev: regulator source
+@@ -975,10 +977,9 @@ static int set_machine_constraints(struc
+ /* If the constraints say the regulator should be on at this point
+ * and we have control then make sure it is enabled.
+ */
+- if ((rdev->constraints->always_on || rdev->constraints->boot_on) &&
+- ops->enable) {
+- ret = ops->enable(rdev);
+- if (ret < 0) {
++ if (rdev->constraints->always_on || rdev->constraints->boot_on) {
++ ret = _regulator_do_enable(rdev);
++ if (ret < 0 && ret != -EINVAL) {
+ rdev_err(rdev, "failed to enable\n");
+ goto out;
+ }
+@@ -3790,9 +3791,8 @@ int regulator_suspend_finish(void)
+ struct regulator_ops *ops = rdev->desc->ops;
+
+ mutex_lock(&rdev->mutex);
+- if ((rdev->use_count > 0 || rdev->constraints->always_on) &&
+- ops->enable) {
+- error = ops->enable(rdev);
++ if (rdev->use_count > 0 || rdev->constraints->always_on) {
++ error = _regulator_do_enable(rdev);
+ if (error)
+ ret = error;
+ } else {
alsa-hda-added-inverted-digital-mic-handling-for-acer-travelmate-8371.patch
alsa-hda-add-missing-loopback-merge-path-for-ad1884-1984-codecs.patch
powerpc-align-p_dyn-p_rela-and-p_st-symbols.patch
+arm-7991-1-sa1100-fix-compile-problem-on-collie.patch
+regulator-core-replace-direct-ops-enable-usage.patch
+x86-ignore-nmis-that-come-in-during-early-boot.patch
+x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch
+x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch
+usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch
+usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch
+genirq-remove-racy-waitqueue_active-check.patch
+cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch
+acpi-resources-ignore-invalid-acpi-device-resources.patch
--- /dev/null
+From e0429362ab15c46ea4d64c3f8c9e0933e48a143a Mon Sep 17 00:00:00 2001
+From: Julius Werner <jwerner@chromium.org>
+Date: Tue, 4 Mar 2014 10:52:39 -0800
+Subject: usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e
+
+From: Julius Werner <jwerner@chromium.org>
+
+commit e0429362ab15c46ea4d64c3f8c9e0933e48a143a upstream.
+
+We've encountered a rare issue when enumerating two Logitech webcams
+after a reboot that doesn't power cycle the USB ports. They are spewing
+random data (possibly some leftover UVC buffers) on the second
+(full-sized) Get Configuration request of the enumeration phase. Since
+the data is random this can potentially cause all kinds of odd behavior,
+and since it occasionally happens multiple times (after the kernel
+issues another reset due to the garbled configuration descriptor), it is
+not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
+around the issue.
+
+Signed-off-by: Julius Werner <jwerner@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/quirks.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/usb/core/quirks.c
++++ b/drivers/usb/core/quirks.c
+@@ -46,6 +46,10 @@ static const struct usb_device_id usb_qu
+ /* Microsoft LifeCam-VX700 v2.0 */
+ { USB_DEVICE(0x045e, 0x0770), .driver_info = USB_QUIRK_RESET_RESUME },
+
++ /* Logitech HD Pro Webcams C920 and C930e */
++ { USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT },
++ { USB_DEVICE(0x046d, 0x0843), .driver_info = USB_QUIRK_DELAY_INIT },
++
+ /* Logitech Quickcam Fusion */
+ { USB_DEVICE(0x046d, 0x08c1), .driver_info = USB_QUIRK_RESET_RESUME },
+
--- /dev/null
+From d86db25e53fa69e3e97f3b55dd82a70689787c5d Mon Sep 17 00:00:00 2001
+From: Julius Werner <jwerner@chromium.org>
+Date: Tue, 4 Mar 2014 11:27:38 -0800
+Subject: usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
+
+From: Julius Werner <jwerner@chromium.org>
+
+commit d86db25e53fa69e3e97f3b55dd82a70689787c5d upstream.
+
+The DELAY_INIT quirk only reduces the frequency of enumeration failures
+with the Logitech HD Pro C920 and C930e webcams, but does not quite
+eliminate them. We have found that adding a delay of 100ms between the
+first and second Get Configuration request makes the device enumerate
+perfectly reliable even after several weeks of extensive testing. The
+reasons for that are anyone's guess, but since the DELAY_INIT quirk
+already delays enumeration by a whole second, wating for another 10th of
+that isn't really a big deal for the one other device that uses it, and
+it will resolve the problems with these webcams.
+
+Signed-off-by: Julius Werner <jwerner@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/config.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/usb/core/config.c
++++ b/drivers/usb/core/config.c
+@@ -718,6 +718,10 @@ int usb_get_configuration(struct usb_dev
+ result = -ENOMEM;
+ goto err;
+ }
++
++ if (dev->quirks & USB_QUIRK_DELAY_INIT)
++ msleep(100);
++
+ result = usb_get_descriptor(dev, USB_DT_CONFIG, cfgno,
+ bigbuffer, length);
+ if (result < 0) {
--- /dev/null
+From 847d7970defb45540735b3fb4e88471c27cacd85 Mon Sep 17 00:00:00 2001
+From: Daniel J Blueman <daniel@numascale.com>
+Date: Thu, 13 Mar 2014 19:43:01 +0800
+Subject: x86/amd/numa: Fix northbridge quirk to assign correct NUMA node
+
+From: Daniel J Blueman <daniel@numascale.com>
+
+commit 847d7970defb45540735b3fb4e88471c27cacd85 upstream.
+
+For systems with multiple servers and routed fabric, all
+northbridges get assigned to the first server. Fix this by also
+using the node reported from the PCI bus. For single-fabric
+systems, the northbriges are on PCI bus 0 by definition, which
+are on NUMA node 0 by definition, so this is invarient on most
+systems.
+
+Tested on fam10h and fam15h single and multi-fabric systems and
+candidate for stable.
+
+Signed-off-by: Daniel J Blueman <daniel@numascale.com>
+Acked-by: Steffen Persvold <sp@numascale.com>
+Acked-by: Borislav Petkov <bp@suse.de>
+Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/quirks.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/quirks.c
++++ b/arch/x86/kernel/quirks.c
+@@ -529,7 +529,7 @@ static void quirk_amd_nb_node(struct pci
+ return;
+
+ pci_read_config_dword(nb_ht, 0x60, &val);
+- node = val & 7;
++ node = pcibus_to_node(dev->bus) | (val & 7);
+ /*
+ * Some hardware may return an invalid node ID,
+ * so check it first:
--- /dev/null
+From b01d4e68933ec23e43b1046fa35d593cefcf37d1 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Fri, 7 Mar 2014 18:58:40 -0800
+Subject: x86: fix compile error due to X86_TRAP_NMI use in asm files
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit b01d4e68933ec23e43b1046fa35d593cefcf37d1 upstream.
+
+It's an enum, not a #define, you can't use it in asm files.
+
+Introduced in commit 5fa10196bdb5 ("x86: Ignore NMIs that come in during
+early boot"), and sadly I didn't compile-test things like I should have
+before pushing out.
+
+My weak excuse is that the x86 tree generally doesn't introduce stupid
+things like this (and the ARM pull afterwards doesn't cause me to do a
+compile-test either, since I don't cross-compile).
+
+Cc: Don Zickus <dzickus@redhat.com>
+Cc: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/head_32.S | 2 +-
+ arch/x86/kernel/head_64.S | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/head_32.S
++++ b/arch/x86/kernel/head_32.S
+@@ -567,7 +567,7 @@ ENDPROC(early_idt_handlers)
+ ENTRY(early_idt_handler)
+ cld
+
+- cmpl $X86_TRAP_NMI,(%esp)
++ cmpl $2,(%esp) # X86_TRAP_NMI
+ je is_nmi # Ignore NMI
+
+ cmpl $2,%ss:early_recursion_flag
+--- a/arch/x86/kernel/head_64.S
++++ b/arch/x86/kernel/head_64.S
+@@ -343,7 +343,7 @@ early_idt_handlers:
+ ENTRY(early_idt_handler)
+ cld
+
+- cmpl $X86_TRAP_NMI,(%rsp)
++ cmpl $2,(%rsp) # X86_TRAP_NMI
+ je is_nmi # Ignore NMI
+
+ cmpl $2,early_recursion_flag(%rip)
--- /dev/null
+From 5fa10196bdb5f190f595ebd048490ee52dddea0f Mon Sep 17 00:00:00 2001
+From: "H. Peter Anvin" <hpa@linux.intel.com>
+Date: Fri, 7 Mar 2014 15:05:20 -0800
+Subject: x86: Ignore NMIs that come in during early boot
+
+From: "H. Peter Anvin" <hpa@linux.intel.com>
+
+commit 5fa10196bdb5f190f595ebd048490ee52dddea0f upstream.
+
+Don Zickus reports:
+
+A customer generated an external NMI using their iLO to test kdump
+worked. Unfortunately, the machine hung. Disabling the nmi_watchdog
+made things work.
+
+I speculated the external NMI fired, caused the machine to panic (as
+expected) and the perf NMI from the watchdog came in and was latched.
+My guess was this somehow caused the hang.
+
+ ----
+
+It appears that the latched NMI stays latched until the early page
+table generation on 64 bits, which causes exceptions to happen which
+end in IRET, which re-enable NMI. Therefore, ignore NMIs that come in
+during early execution, until we have proper exception handling.
+
+Reported-and-tested-by: Don Zickus <dzickus@redhat.com>
+Link: http://lkml.kernel.org/r/1394221143-29713-1-git-send-email-dzickus@redhat.com
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/head_32.S | 7 ++++++-
+ arch/x86/kernel/head_64.S | 6 +++++-
+ 2 files changed, 11 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/head_32.S
++++ b/arch/x86/kernel/head_32.S
+@@ -566,6 +566,10 @@ ENDPROC(early_idt_handlers)
+ /* This is global to keep gas from relaxing the jumps */
+ ENTRY(early_idt_handler)
+ cld
++
++ cmpl $X86_TRAP_NMI,(%esp)
++ je is_nmi # Ignore NMI
++
+ cmpl $2,%ss:early_recursion_flag
+ je hlt_loop
+ incl %ss:early_recursion_flag
+@@ -616,8 +620,9 @@ ex_entry:
+ pop %edx
+ pop %ecx
+ pop %eax
+- addl $8,%esp /* drop vector number and error code */
+ decl %ss:early_recursion_flag
++is_nmi:
++ addl $8,%esp /* drop vector number and error code */
+ iret
+ ENDPROC(early_idt_handler)
+
+--- a/arch/x86/kernel/head_64.S
++++ b/arch/x86/kernel/head_64.S
+@@ -343,6 +343,9 @@ early_idt_handlers:
+ ENTRY(early_idt_handler)
+ cld
+
++ cmpl $X86_TRAP_NMI,(%rsp)
++ je is_nmi # Ignore NMI
++
+ cmpl $2,early_recursion_flag(%rip)
+ jz 1f
+ incl early_recursion_flag(%rip)
+@@ -405,8 +408,9 @@ ENTRY(early_idt_handler)
+ popq %rdx
+ popq %rcx
+ popq %rax
+- addq $16,%rsp # drop vector number and error code
+ decl early_recursion_flag(%rip)
++is_nmi:
++ addq $16,%rsp # drop vector number and error code
+ INTERRUPT_RETURN
+ ENDPROC(early_idt_handler)
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
