]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 2 Jul 2014 21:39:23 +0000 (14:39 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 2 Jul 2014 21:39:23 +0000 (14:39 -0700)
added patches:
input-elantech-deal-with-clickpads-reporting-right-button-events.patch
mips-msc-prevent-out-of-bounds-writes-to-mips-sc-ioremap-d-region.patch
pci-add-new-id-for-intel-gpu-spurious-interrupt-quirk.patch
pci-fix-incorrect-vgaarb-conditional-in-warn_on.patch
recordmcount-mips-fix-possible-incorrect-mcount_loc-table-entries-in-modules.patch

queue-3.4/input-elantech-deal-with-clickpads-reporting-right-button-events.patch [new file with mode: 0644]
queue-3.4/mips-msc-prevent-out-of-bounds-writes-to-mips-sc-ioremap-d-region.patch [new file with mode: 0644]
queue-3.4/pci-add-new-id-for-intel-gpu-spurious-interrupt-quirk.patch [new file with mode: 0644]
queue-3.4/pci-fix-incorrect-vgaarb-conditional-in-warn_on.patch [new file with mode: 0644]
queue-3.4/recordmcount-mips-fix-possible-incorrect-mcount_loc-table-entries-in-modules.patch [new file with mode: 0644]
queue-3.4/series

diff --git a/queue-3.4/input-elantech-deal-with-clickpads-reporting-right-button-events.patch b/queue-3.4/input-elantech-deal-with-clickpads-reporting-right-button-events.patch
new file mode 100644 (file)
index 0000000..af6e7a3
--- /dev/null
@@ -0,0 +1,79 @@
+From cd9e83e2754465856097f31c7ab933ce74c473f8 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Sat, 7 Jun 2014 22:35:07 -0700
+Subject: Input: elantech - deal with clickpads reporting right button events
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit cd9e83e2754465856097f31c7ab933ce74c473f8 upstream.
+
+At least the Dell Vostro 5470 elantech *clickpad* reports right button
+clicks when clicked in the right bottom area:
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1103528
+
+This is different from how (elantech) clickpads normally operate, normally
+no matter where the user clicks on the pad the pad always reports a left
+button event, since there is only 1 hardware button beneath the path.
+
+It looks like Dell has put 2 buttons under the pad, one under each bottom
+corner, causing this.
+
+Since this however still clearly is a real clickpad hardware-wise, we still
+want to report it as such to userspace, so that things like finger movement
+in the bottom area can be properly ignored as it should be on clickpads.
+
+So deal with this weirdness by simply mapping a right click to a left click
+on elantech clickpads. As an added advantage this is something which we can
+simply do on all elantech clickpads, so no need to add special quirks for
+this weird model.
+
+Reported-and-tested-by: Elder Marco <eldermarco@gmail.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elantech.c |   22 ++++++++++++++++++----
+ 1 file changed, 18 insertions(+), 4 deletions(-)
+
+--- a/drivers/input/mouse/elantech.c
++++ b/drivers/input/mouse/elantech.c
+@@ -472,8 +472,15 @@ static void elantech_report_absolute_v3(
+       input_report_key(dev, BTN_TOOL_FINGER, fingers == 1);
+       input_report_key(dev, BTN_TOOL_DOUBLETAP, fingers == 2);
+       input_report_key(dev, BTN_TOOL_TRIPLETAP, fingers == 3);
+-      input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
+-      input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
++
++      /* For clickpads map both buttons to BTN_LEFT */
++      if (etd->fw_version & 0x001000) {
++              input_report_key(dev, BTN_LEFT, packet[0] & 0x03);
++      } else {
++              input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
++              input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
++      }
++
+       input_report_abs(dev, ABS_PRESSURE, pres);
+       input_report_abs(dev, ABS_TOOL_WIDTH, width);
+@@ -483,10 +490,17 @@ static void elantech_report_absolute_v3(
+ static void elantech_input_sync_v4(struct psmouse *psmouse)
+ {
+       struct input_dev *dev = psmouse->dev;
++      struct elantech_data *etd = psmouse->private;
+       unsigned char *packet = psmouse->packet;
+-      input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
+-      input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
++      /* For clickpads map both buttons to BTN_LEFT */
++      if (etd->fw_version & 0x001000) {
++              input_report_key(dev, BTN_LEFT, packet[0] & 0x03);
++      } else {
++              input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
++              input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
++      }
++
+       input_mt_report_pointer_emulation(dev, true);
+       input_sync(dev);
+ }
diff --git a/queue-3.4/mips-msc-prevent-out-of-bounds-writes-to-mips-sc-ioremap-d-region.patch b/queue-3.4/mips-msc-prevent-out-of-bounds-writes-to-mips-sc-ioremap-d-region.patch
new file mode 100644 (file)
index 0000000..4312ce9
--- /dev/null
@@ -0,0 +1,51 @@
+From ab6c15bc6620ebe220970cc040b29bcb2757f373 Mon Sep 17 00:00:00 2001
+From: Markos Chandras <markos.chandras@imgtec.com>
+Date: Mon, 23 Jun 2014 09:48:51 +0100
+Subject: MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremap'd region
+
+From: Markos Chandras <markos.chandras@imgtec.com>
+
+commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream.
+
+Previously, the lower limit for the MIPS SC initialization loop was
+set incorrectly allowing one extra loop leading to writes
+beyond the MSC ioremap'd space. More precisely, the value of the 'imp'
+in the last loop increased beyond the msc_irqmap_t boundaries and
+as a result of which, the 'n' variable was loaded with an incorrect
+value. This value was used later on to calculate the offset in the
+MSC01_IC_SUP which led to random crashes like the following one:
+
+CPU 0 Unable to handle kernel paging request at virtual address e75c0200,
+epc == 8058dba4, ra == 8058db90
+[...]
+Call Trace:
+[<8058dba4>] init_msc_irqs+0x104/0x154
+[<8058b5bc>] arch_init_irq+0xd8/0x154
+[<805897b0>] start_kernel+0x220/0x36c
+
+Kernel panic - not syncing: Attempted to kill the idle task!
+
+This patch fixes the problem
+
+Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
+Reviewed-by: James Hogan <james.hogan@imgtec.com>
+Cc: linux-mips@linux-mips.org
+Patchwork: https://patchwork.linux-mips.org/patch/7118/
+Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/kernel/irq-msc01.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/mips/kernel/irq-msc01.c
++++ b/arch/mips/kernel/irq-msc01.c
+@@ -131,7 +131,7 @@ void __init init_msc_irqs(unsigned long
+       board_bind_eic_interrupt = &msc_bind_eic_interrupt;
+-      for (; nirq >= 0; nirq--, imp++) {
++      for (; nirq > 0; nirq--, imp++) {
+               int n = imp->im_irq;
+               switch (imp->im_type) {
diff --git a/queue-3.4/pci-add-new-id-for-intel-gpu-spurious-interrupt-quirk.patch b/queue-3.4/pci-add-new-id-for-intel-gpu-spurious-interrupt-quirk.patch
new file mode 100644 (file)
index 0000000..a06ac95
--- /dev/null
@@ -0,0 +1,40 @@
+From 7c82126a94e69bbbac586f0249e7ef11e681246c Mon Sep 17 00:00:00 2001
+From: Thomas Jarosch <thomas.jarosch@intra2net.com>
+Date: Mon, 7 Apr 2014 15:10:32 +0200
+Subject: PCI: Add new ID for Intel GPU "spurious interrupt" quirk
+
+From: Thomas Jarosch <thomas.jarosch@intra2net.com>
+
+commit 7c82126a94e69bbbac586f0249e7ef11e681246c upstream.
+
+After a CPU upgrade while keeping the same mainboard, we faced "spurious
+interrupt" problems again.
+
+It turned out that the new CPU also featured a new GPU with a different PCI
+ID.
+
+Add this PCI ID to the quirk table.  Probably all other Intel GPU PCI IDs
+are affected, too, but I don't want to add them without a test system.
+
+See f67fd55fa96f ("PCI: Add quirk for still enabled interrupts on Intel
+Sandy Bridge GPUs") for some history.
+
+[bhelgaas: add f67fd55fa96f reference, stable tag]
+Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/quirks.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -2921,6 +2921,7 @@ static void __devinit disable_igfx_irq(s
+ }
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0152, disable_igfx_irq);
+ static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
+                         struct pci_fixup *end)
diff --git a/queue-3.4/pci-fix-incorrect-vgaarb-conditional-in-warn_on.patch b/queue-3.4/pci-fix-incorrect-vgaarb-conditional-in-warn_on.patch
new file mode 100644 (file)
index 0000000..b37eb3c
--- /dev/null
@@ -0,0 +1,37 @@
+From 67ebd8140dc8923c65451fa0f6a8eee003c4dcd3 Mon Sep 17 00:00:00 2001
+From: Bjorn Helgaas <bhelgaas@google.com>
+Date: Sat, 5 Apr 2014 15:14:22 -0600
+Subject: PCI: Fix incorrect vgaarb conditional in WARN_ON()
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+commit 67ebd8140dc8923c65451fa0f6a8eee003c4dcd3 upstream.
+
+3448a19da479 "vgaarb: use bridges to control VGA routing where possible"
+added the "flags & PCI_VGA_STATE_CHANGE_DECODES" condition to an existing
+WARN_ON(), but used bitwise AND (&) instead of logical AND (&&), so the
+condition is never true.  Replace with logical AND.
+
+Found by Coverity (CID 142811).
+
+Fixes: 3448a19da479 "vgaarb: use bridges to control VGA routing where possible"
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Acked-by: Yinghai Lu <yinghai@kernel.org>
+Acked-by: David Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/pci.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -3610,7 +3610,7 @@ int pci_set_vga_state(struct pci_dev *de
+       u16 cmd;
+       int rc;
+-      WARN_ON((flags & PCI_VGA_STATE_CHANGE_DECODES) & (command_bits & ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY)));
++      WARN_ON((flags & PCI_VGA_STATE_CHANGE_DECODES) && (command_bits & ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY)));
+       /* ARCH specific VGA enables */
+       rc = pci_set_vga_state_arch(dev, decode, command_bits, flags);
diff --git a/queue-3.4/recordmcount-mips-fix-possible-incorrect-mcount_loc-table-entries-in-modules.patch b/queue-3.4/recordmcount-mips-fix-possible-incorrect-mcount_loc-table-entries-in-modules.patch
new file mode 100644 (file)
index 0000000..44cea6d
--- /dev/null
@@ -0,0 +1,62 @@
+From 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 Mon Sep 17 00:00:00 2001
+From: Alex Smith <alex.smith@imgtec.com>
+Date: Tue, 17 Jun 2014 10:39:53 +0100
+Subject: recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules
+
+From: Alex Smith <alex.smith@imgtec.com>
+
+commit 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 upstream.
+
+On MIPS calls to _mcount in modules generate 2 instructions to load
+the _mcount address (and therefore 2 relocations). The mcount_loc
+table should only reference the first of these, so the second is
+filtered out by checking the relocation offset and ignoring ones that
+immediately follow the previous one seen.
+
+However if a module has an _mcount call at offset 0, the second
+relocation would not be filtered out due to old_r_offset == 0
+being taken to mean that the current relocation is the first one
+seen, and both would end up in the mcount_loc table.
+
+This results in ftrace_make_nop() patching both (adjacent)
+instructions to branches over the _mcount call sequence like so:
+
+  0xffffffffc08a8000:  04 00 00 10     b       0xffffffffc08a8014
+  0xffffffffc08a8004:  04 00 00 10     b       0xffffffffc08a8018
+  0xffffffffc08a8008:  2d 08 e0 03     move    at,ra
+  ...
+
+The second branch is in the delay slot of the first, which is
+defined to be unpredictable - on the platform on which this bug was
+encountered, it triggers a reserved instruction exception.
+
+Fix by initializing old_r_offset to ~0 and using that instead of 0
+to determine whether the current relocation is the first seen.
+
+Signed-off-by: Alex Smith <alex.smith@imgtec.com>
+Cc: linux-kernel@vger.kernel.org
+Cc: linux-mips@linux-mips.org
+Patchwork: https://patchwork.linux-mips.org/patch/7098/
+Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ scripts/recordmcount.h |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/scripts/recordmcount.h
++++ b/scripts/recordmcount.h
+@@ -163,11 +163,11 @@ static int mcount_adjust = 0;
+ static int MIPS_is_fake_mcount(Elf_Rel const *rp)
+ {
+-      static Elf_Addr old_r_offset;
++      static Elf_Addr old_r_offset = ~(Elf_Addr)0;
+       Elf_Addr current_r_offset = _w(rp->r_offset);
+       int is_fake;
+-      is_fake = old_r_offset &&
++      is_fake = (old_r_offset != ~(Elf_Addr)0) &&
+               (current_r_offset - old_r_offset == MIPS_FAKEMCOUNT_OFFSET);
+       old_r_offset = current_r_offset;
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..6bd135b5df28b981b761b3f84c85605ae1572369 100644 (file)
@@ -0,0 +1,5 @@
+input-elantech-deal-with-clickpads-reporting-right-button-events.patch
+pci-add-new-id-for-intel-gpu-spurious-interrupt-quirk.patch
+pci-fix-incorrect-vgaarb-conditional-in-warn_on.patch
+recordmcount-mips-fix-possible-incorrect-mcount_loc-table-entries-in-modules.patch
+mips-msc-prevent-out-of-bounds-writes-to-mips-sc-ioremap-d-region.patch