--- /dev/null
+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
+@@ -473,8 +473,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);
+
+@@ -484,10 +491,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);
+ }
--- /dev/null
+From fb4f8f568a9def02240ef9bf7aabd246dc63a081 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Sat, 7 Jun 2014 23:07:13 -0700
+Subject: Input: elantech - don't set bit 1 of reg_10 when the no_hw_res quirk is set
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit fb4f8f568a9def02240ef9bf7aabd246dc63a081 upstream.
+
+The touchpad on the GIGABYTE U2442 not only stops communicating when we try
+to set bit 3 (enable real hardware resolution) of reg_10, but on some BIOS
+versions also when we set bit 1 (enable two finger mode auto correct).
+
+I've asked the original reporter of:
+https://bugzilla.kernel.org/show_bug.cgi?id=61151
+
+To check that not setting bit 1 does not lead to any adverse effects on his
+model / BIOS revision, and it does not, so this commit fixes the touchpad
+not working on these versions by simply never setting bit 1 for laptop
+models with the no_hw_res quirk.
+
+Reported-and-tested-by: James Lademann <jwlademann@gmail.com>
+Tested-by: Philipp Wolfer <ph.wolfer@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 | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/input/mouse/elantech.c
++++ b/drivers/input/mouse/elantech.c
+@@ -819,7 +819,7 @@ static int elantech_set_absolute_mode(st
+ if (etd->set_hw_resolution)
+ etd->reg_10 = 0x0b;
+ else
+- etd->reg_10 = 0x03;
++ etd->reg_10 = 0x01;
+
+ if (elantech_write_reg(psmouse, 0x10, etd->reg_10))
+ rc = -1;
+@@ -1320,7 +1320,8 @@ static int elantech_reconnect(struct psm
+ }
+
+ /*
+- * Some hw_version 3 models go into error state when we try to set bit 3 of r10
++ * Some hw_version 3 models go into error state when we try to set
++ * bit 3 and/or bit 1 of r10.
+ */
+ static const struct dmi_system_id no_hw_res_dmi_table[] = {
+ #if defined(CONFIG_DMI) && defined(CONFIG_X86)
--- /dev/null
+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) {
--- /dev/null
+From d1e714db8129a1d3670e449b87719c78e2c76f9f Mon Sep 17 00:00:00 2001
+From: Asai Thambi S P <asamymuthupa@micron.com>
+Date: Thu, 13 Mar 2014 18:45:15 -0700
+Subject: mtip32xx: Fix ERO and NoSnoop values in PCIe upstream on AMD systems
+
+From: Asai Thambi S P <asamymuthupa@micron.com>
+
+commit d1e714db8129a1d3670e449b87719c78e2c76f9f upstream.
+
+A hardware quirk in P320h/P420m interfere with PCIe transactions on some
+AMD chipsets, making P320h/P420m unusable. This workaround is to disable
+ERO and NoSnoop bits in the parent and root complex for normal
+functioning of these devices
+
+NOTE: This workaround is specific to AMD chipset with a PCIe upstream
+device with device id 0x5aXX
+
+Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
+Signed-off-by: Sam Bradshaw <sbradshaw@micron.com>
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/mtip32xx/mtip32xx.c | 53 ++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 53 insertions(+)
+
+--- a/drivers/block/mtip32xx/mtip32xx.c
++++ b/drivers/block/mtip32xx/mtip32xx.c
+@@ -4284,6 +4284,57 @@ static DEFINE_HANDLER(5);
+ static DEFINE_HANDLER(6);
+ static DEFINE_HANDLER(7);
+
++static void mtip_disable_link_opts(struct driver_data *dd, struct pci_dev *pdev)
++{
++ int pos;
++ unsigned short pcie_dev_ctrl;
++
++ pos = pci_find_capability(pdev, PCI_CAP_ID_EXP);
++ if (pos) {
++ pci_read_config_word(pdev,
++ pos + PCI_EXP_DEVCTL,
++ &pcie_dev_ctrl);
++ if (pcie_dev_ctrl & (1 << 11) ||
++ pcie_dev_ctrl & (1 << 4)) {
++ dev_info(&dd->pdev->dev,
++ "Disabling ERO/No-Snoop on bridge device %04x:%04x\n",
++ pdev->vendor, pdev->device);
++ pcie_dev_ctrl &= ~(PCI_EXP_DEVCTL_NOSNOOP_EN |
++ PCI_EXP_DEVCTL_RELAX_EN);
++ pci_write_config_word(pdev,
++ pos + PCI_EXP_DEVCTL,
++ pcie_dev_ctrl);
++ }
++ }
++}
++
++static void mtip_fix_ero_nosnoop(struct driver_data *dd, struct pci_dev *pdev)
++{
++ /*
++ * This workaround is specific to AMD/ATI chipset with a PCI upstream
++ * device with device id 0x5aXX
++ */
++ if (pdev->bus && pdev->bus->self) {
++ if (pdev->bus->self->vendor == PCI_VENDOR_ID_ATI &&
++ ((pdev->bus->self->device & 0xff00) == 0x5a00)) {
++ mtip_disable_link_opts(dd, pdev->bus->self);
++ } else {
++ /* Check further up the topology */
++ struct pci_dev *parent_dev = pdev->bus->self;
++ if (parent_dev->bus &&
++ parent_dev->bus->parent &&
++ parent_dev->bus->parent->self &&
++ parent_dev->bus->parent->self->vendor ==
++ PCI_VENDOR_ID_ATI &&
++ (parent_dev->bus->parent->self->device &
++ 0xff00) == 0x5a00) {
++ mtip_disable_link_opts(dd,
++ parent_dev->bus->parent->self);
++ }
++ }
++ }
++}
++
+ /*
+ * Called for each supported PCI device detected.
+ *
+@@ -4435,6 +4486,8 @@ static int mtip_pci_probe(struct pci_dev
+ goto block_initialize_err;
+ }
+
++ mtip_fix_ero_nosnoop(dd, pdev);
++
+ /* Initialize the block layer. */
+ rv = mtip_block_initialize(dd);
+ if (rv < 0) {
--- /dev/null
+From 670a641420a3d9586eebe7429dfeec4e7ed447aa Mon Sep 17 00:00:00 2001
+From: Asai Thambi S P <asamymuthupa@micron.com>
+Date: Wed, 16 Apr 2014 20:27:54 -0700
+Subject: mtip32xx: Increase timeout for STANDBY IMMEDIATE command
+
+From: Asai Thambi S P <asamymuthupa@micron.com>
+
+commit 670a641420a3d9586eebe7429dfeec4e7ed447aa upstream.
+
+Increased timeout for STANDBY IMMEDIATE command to 2 minutes.
+
+Signed-off-by: Selvan Mani <smani@micron.com>
+Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/mtip32xx/mtip32xx.c | 66 ++++++++++++++++++++------------------
+ 1 file changed, 35 insertions(+), 31 deletions(-)
+
+--- a/drivers/block/mtip32xx/mtip32xx.c
++++ b/drivers/block/mtip32xx/mtip32xx.c
+@@ -1493,6 +1493,37 @@ static inline void ata_swap_string(u16 *
+ be16_to_cpus(&buf[i]);
+ }
+
++static void mtip_set_timeout(struct driver_data *dd,
++ struct host_to_dev_fis *fis,
++ unsigned int *timeout, u8 erasemode)
++{
++ switch (fis->command) {
++ case ATA_CMD_DOWNLOAD_MICRO:
++ *timeout = 120000; /* 2 minutes */
++ break;
++ case ATA_CMD_SEC_ERASE_UNIT:
++ case 0xFC:
++ if (erasemode)
++ *timeout = ((*(dd->port->identify + 90) * 2) * 60000);
++ else
++ *timeout = ((*(dd->port->identify + 89) * 2) * 60000);
++ break;
++ case ATA_CMD_STANDBYNOW1:
++ *timeout = 120000; /* 2 minutes */
++ break;
++ case 0xF7:
++ case 0xFA:
++ *timeout = 60000; /* 60 seconds */
++ break;
++ case ATA_CMD_SMART:
++ *timeout = 15000; /* 15 seconds */
++ break;
++ default:
++ *timeout = MTIP_IOCTL_COMMAND_TIMEOUT_MS;
++ break;
++ }
++}
++
+ /*
+ * Request the device identity information.
+ *
+@@ -1602,6 +1633,7 @@ static int mtip_standby_immediate(struct
+ int rv;
+ struct host_to_dev_fis fis;
+ unsigned long start;
++ unsigned int timeout;
+
+ /* Build the FIS. */
+ memset(&fis, 0, sizeof(struct host_to_dev_fis));
+@@ -1609,6 +1641,8 @@ static int mtip_standby_immediate(struct
+ fis.opts = 1 << 7;
+ fis.command = ATA_CMD_STANDBYNOW1;
+
++ mtip_set_timeout(port->dd, &fis, &timeout, 0);
++
+ start = jiffies;
+ rv = mtip_exec_internal_command(port,
+ &fis,
+@@ -1617,7 +1651,7 @@ static int mtip_standby_immediate(struct
+ 0,
+ 0,
+ GFP_ATOMIC,
+- 15000);
++ timeout);
+ dbg_printk(MTIP_DRV_NAME "Time taken to complete standby cmd: %d ms\n",
+ jiffies_to_msecs(jiffies - start));
+ if (rv)
+@@ -2156,36 +2190,6 @@ static unsigned int implicit_sector(unsi
+ }
+ return rv;
+ }
+-static void mtip_set_timeout(struct driver_data *dd,
+- struct host_to_dev_fis *fis,
+- unsigned int *timeout, u8 erasemode)
+-{
+- switch (fis->command) {
+- case ATA_CMD_DOWNLOAD_MICRO:
+- *timeout = 120000; /* 2 minutes */
+- break;
+- case ATA_CMD_SEC_ERASE_UNIT:
+- case 0xFC:
+- if (erasemode)
+- *timeout = ((*(dd->port->identify + 90) * 2) * 60000);
+- else
+- *timeout = ((*(dd->port->identify + 89) * 2) * 60000);
+- break;
+- case ATA_CMD_STANDBYNOW1:
+- *timeout = 120000; /* 2 minutes */
+- break;
+- case 0xF7:
+- case 0xFA:
+- *timeout = 60000; /* 60 seconds */
+- break;
+- case ATA_CMD_SMART:
+- *timeout = 15000; /* 15 seconds */
+- break;
+- default:
+- *timeout = MTIP_IOCTL_COMMAND_TIMEOUT_MS;
+- break;
+- }
+-}
+
+ /*
+ * Executes a taskfile
--- /dev/null
+From af5ded8ccf21627f9614afc03b356712666ed225 Mon Sep 17 00:00:00 2001
+From: Asai Thambi S P <asamymuthupa@micron.com>
+Date: Wed, 16 Apr 2014 20:30:16 -0700
+Subject: mtip32xx: Remove dfs_parent after pci unregister
+
+From: Asai Thambi S P <asamymuthupa@micron.com>
+
+commit af5ded8ccf21627f9614afc03b356712666ed225 upstream.
+
+In module exit, dfs_parent and it's subtree were removed before
+unregistering with pci. When debugfs entry for each device is attempted
+to remove in pci_remove() context, they don't exist, as dfs_parent and
+its children were already ripped apart.
+
+Modified to first unregister with pci and then remove dfs_parent.
+
+Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/mtip32xx/mtip32xx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/block/mtip32xx/mtip32xx.c
++++ b/drivers/block/mtip32xx/mtip32xx.c
+@@ -4784,13 +4784,13 @@ static int __init mtip_init(void)
+ */
+ static void __exit mtip_exit(void)
+ {
+- debugfs_remove_recursive(dfs_parent);
+-
+ /* Release the allocated major block device number. */
+ unregister_blkdev(mtip_major, MTIP_DRV_NAME);
+
+ /* Unregister the PCI driver. */
+ pci_unregister_driver(&mtip_pci_driver);
++
++ debugfs_remove_recursive(dfs_parent);
+ }
+
+ MODULE_AUTHOR("Micron Technology, Inc");
--- /dev/null
+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
+@@ -2930,6 +2930,7 @@ static void disable_igfx_irq(struct pci_
+ }
+ 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);
+
+ /*
+ * Some devices may pass our check in pci_intx_mask_supported if
--- /dev/null
+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
+@@ -3659,7 +3659,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);
--- /dev/null
+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;
+
target-fix-left-over-se_lun-lun_sep-pointer-oops.patch
iscsi-target-avoid-rejecting-incorrect-itt-for-data-out.patch
iscsi-target-explicily-clear-login-response-pdu-in-exception-path.patch
+input-elantech-deal-with-clickpads-reporting-right-button-events.patch
+input-elantech-don-t-set-bit-1-of-reg_10-when-the-no_hw_res-quirk-is-set.patch
+pci-add-new-id-for-intel-gpu-spurious-interrupt-quirk.patch
+pci-fix-incorrect-vgaarb-conditional-in-warn_on.patch
+mtip32xx-fix-ero-and-nosnoop-values-in-pcie-upstream-on-amd-systems.patch
+mtip32xx-increase-timeout-for-standby-immediate-command.patch
+mtip32xx-remove-dfs_parent-after-pci-unregister.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