]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.10-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 7 Dec 2014 06:22:48 +0000 (22:22 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 7 Dec 2014 06:22:48 +0000 (22:22 -0800)
added patches:
drm-i915-unlock-panel-even-when-lvds-is-disabled.patch
drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch
i2c-davinci-generate-stp-always-when-nack-is-received.patch
i2c-omap-fix-i207-errata-handling.patch
i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch
media-smiapp-only-some-selection-targets-are-settable.patch
mm-fix-swapoff-hang-after-page-migration-and-fork.patch
mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch
xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch

12 files changed:
queue-3.10/drm-i915-unlock-panel-even-when-lvds-is-disabled.patch [new file with mode: 0644]
queue-3.10/drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch [new file with mode: 0644]
queue-3.10/i2c-davinci-generate-stp-always-when-nack-is-received.patch [new file with mode: 0644]
queue-3.10/i2c-omap-fix-i207-errata-handling.patch [new file with mode: 0644]
queue-3.10/i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch [new file with mode: 0644]
queue-3.10/media-smiapp-only-some-selection-targets-are-settable.patch [new file with mode: 0644]
queue-3.10/mm-fix-swapoff-hang-after-page-migration-and-fork.patch [new file with mode: 0644]
queue-3.10/mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch [new file with mode: 0644]
queue-3.10/series [new file with mode: 0644]
queue-3.10/xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch [new file with mode: 0644]
queue-3.14/series [new file with mode: 0644]
queue-3.17/series [new file with mode: 0644]

diff --git a/queue-3.10/drm-i915-unlock-panel-even-when-lvds-is-disabled.patch b/queue-3.10/drm-i915-unlock-panel-even-when-lvds-is-disabled.patch
new file mode 100644 (file)
index 0000000..edbda1f
--- /dev/null
@@ -0,0 +1,70 @@
+From b0616c5306b342ceca07044dbc4f917d95c4f825 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Mon, 1 Dec 2014 17:56:54 +0100
+Subject: drm/i915: Unlock panel even when LVDS is disabled
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit b0616c5306b342ceca07044dbc4f917d95c4f825 upstream.
+
+Otherwise we'll have backtraces in assert_panel_unlocked because the
+BIOS locks the register. In the reporter's case this regression was
+introduced in
+
+commit c31407a3672aaebb4acddf90944a114fa5c8af7b
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date:   Thu Oct 18 21:07:01 2012 +0100
+
+    drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
+
+Reported-by: Alexey Orishko <alexey.orishko@gmail.com>
+Cc: Alexey Orishko <alexey.orishko@gmail.com>
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Francois Tigeot <ftigeot@wolfpond.org>
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Tested-by: Alexey Orishko <alexey.orishko@gmail.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_lvds.c |   22 +++++++++++-----------
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_lvds.c
++++ b/drivers/gpu/drm/i915/intel_lvds.c
+@@ -1097,6 +1097,17 @@ bool intel_lvds_init(struct drm_device *
+       int pipe;
+       u8 pin;
++      /*
++       * Unlock registers and just leave them unlocked. Do this before
++       * checking quirk lists to avoid bogus WARNINGs.
++       */
++      if (HAS_PCH_SPLIT(dev)) {
++              I915_WRITE(PCH_PP_CONTROL,
++                         I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
++      } else {
++              I915_WRITE(PP_CONTROL,
++                         I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
++      }
+       if (!intel_lvds_supported(dev))
+               return false;
+@@ -1280,17 +1291,6 @@ out:
+       DRM_DEBUG_KMS("detected %s-link lvds configuration\n",
+                     lvds_encoder->is_dual_link ? "dual" : "single");
+-      /*
+-       * Unlock registers and just
+-       * leave them unlocked
+-       */
+-      if (HAS_PCH_SPLIT(dev)) {
+-              I915_WRITE(PCH_PP_CONTROL,
+-                         I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
+-      } else {
+-              I915_WRITE(PP_CONTROL,
+-                         I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
+-      }
+       lvds_connector->lid_notifier.notifier_call = intel_lid_notify;
+       if (acpi_lid_notifier_register(&lvds_connector->lid_notifier)) {
+               DRM_DEBUG_KMS("lid notifier registration failed\n");
diff --git a/queue-3.10/drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch b/queue-3.10/drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch
new file mode 100644 (file)
index 0000000..053467e
--- /dev/null
@@ -0,0 +1,133 @@
+From f5475cc43c899e33098d4db44b7c5e710f16589d Mon Sep 17 00:00:00 2001
+From: Petr Mladek <pmladek@suse.cz>
+Date: Thu, 27 Nov 2014 16:57:21 +0100
+Subject: drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6
+
+From: Petr Mladek <pmladek@suse.cz>
+
+commit f5475cc43c899e33098d4db44b7c5e710f16589d upstream.
+
+I was unable too boot 3.18.0-rc6 because of the following kernel
+panic in drm_calc_vbltimestamp_from_scanoutpos():
+
+    [drm] Initialized drm 1.1.0 20060810
+    [drm] radeon kernel modesetting enabled.
+    [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
+    [drm] register mmio base: 0xC8400000
+    [drm] register mmio size: 65536
+    radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
+    radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
+    [drm] Detected VRAM RAM=128M, BAR=128M
+    [drm] RAM width 16bits DDR
+    [TTM] Zone  kernel: Available graphics memory: 3829346 kiB
+    [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
+    [TTM] Initializing pool allocator
+    [TTM] Initializing DMA pool allocator
+    [drm] radeon: 16M of VRAM memory ready
+    [drm] radeon: 512M of GTT memory ready.
+    [drm] GART: num cpu pages 131072, num gpu pages 131072
+    [drm] PCI GART of 512M enabled (table at 0x0000000037880000).
+    radeon 0000:0b:01.0: WB disabled
+    radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
+    [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
+    [drm] Driver supports precise vblank timestamp query.
+    [drm] radeon: irq initialized.
+    [drm] Loading R100 Microcode
+    radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
+    radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
+    [drm:r100_cp_init] *ERROR* Failed to load firmware!
+    radeon 0000:0b:01.0: failed initializing CP (-2).
+    radeon 0000:0b:01.0: Disabling GPU acceleration
+    [drm] radeon: cp finalized
+    BUG: unable to handle kernel NULL pointer dereference at 000000000000025c
+    IP: [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
+    PGD 0
+    Oops: 0000 [#1] SMP
+    Modules linked in:
+    CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
+    Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
+    task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000
+    RIP: 0010:[<ffffffff8150423b>]  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
+    RSP: 0000:ffff880234da7918  EFLAGS: 00010086
+    RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48
+    RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000
+    RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000
+    R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0
+    R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000
+    FS:  0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
+    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
+    CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0
+    Stack:
+     ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
+     ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
+     ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
+    Call Trace:
+     [<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110
+     [<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60
+     [<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180
+     [<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70
+     [<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0
+     [<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70
+     [<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0
+     [<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70
+     [<ffffffff8156c07e>] r100_init+0x26e/0x410
+     [<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50
+     [<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210
+     [<ffffffff81506965>] drm_dev_register+0xb5/0x110
+     [<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200
+     [<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0
+     [<ffffffff8141a365>] local_pci_probe+0x45/0xa0
+     [<ffffffff8141b741>] pci_device_probe+0xd1/0x130
+     [<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0
+     [<ffffffff8163413b>] __driver_attach+0x9b/0xa0
+     [<ffffffff816340a0>] ? __device_attach+0x40/0x40
+     [<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0
+     [<ffffffff8163378e>] driver_attach+0x1e/0x20
+     [<ffffffff81633390>] bus_add_driver+0x180/0x240
+     [<ffffffff81634914>] driver_register+0x64/0xf0
+     [<ffffffff81419cac>] __pci_register_driver+0x4c/0x50
+     [<ffffffff81509bf5>] drm_pci_init+0xf5/0x120
+     [<ffffffff821dc871>] ? ttm_init+0x6a/0x6a
+     [<ffffffff821dc908>] radeon_init+0x97/0xb5
+     [<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0
+     [<ffffffff810e3278>] ? __wake_up+0x48/0x60
+     [<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215
+     [<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0
+     [<ffffffff818a78f0>] ? rest_init+0x80/0x80
+     [<ffffffff818a78fe>] kernel_init+0xe/0xf0
+     [<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0
+     [<ffffffff818a78f0>] ? rest_init+0x80/0x80
+    Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
+    RIP  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
+     RSP <ffff880234da7918>
+    CR2: 000000000000025c
+    ---[ end trace ad2c0aadf48e2032 ]---
+    Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
+
+It has helped me to add a NULL pointer check that was suggested at
+http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html
+
+I am not familiar with the code. But the change looks sane
+and we need something fast at this stage of 3.18 development.
+
+Suggested-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Petr Mladek <pmladek@suse.cz>
+Tested-by: Petr Mladek <pmladek@suse.cz>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_kms.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/radeon_kms.c
++++ b/drivers/gpu/drm/radeon/radeon_kms.c
+@@ -666,6 +666,8 @@ int radeon_get_vblank_timestamp_kms(stru
+       /* Get associated drm_crtc: */
+       drmcrtc = &rdev->mode_info.crtcs[crtc]->base;
++      if (!drmcrtc)
++              return -EINVAL;
+       /* Helper routine in DRM core does all the work: */
+       return drm_calc_vbltimestamp_from_scanoutpos(dev, crtc, max_error,
diff --git a/queue-3.10/i2c-davinci-generate-stp-always-when-nack-is-received.patch b/queue-3.10/i2c-davinci-generate-stp-always-when-nack-is-received.patch
new file mode 100644 (file)
index 0000000..5e27558
--- /dev/null
@@ -0,0 +1,65 @@
+From 9ea359f7314132cbcb5a502d2d8ef095be1f45e4 Mon Sep 17 00:00:00 2001
+From: Grygorii Strashko <grygorii.strashko@ti.com>
+Date: Mon, 1 Dec 2014 17:34:04 +0200
+Subject: i2c: davinci: generate STP always when NACK is received
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Grygorii Strashko <grygorii.strashko@ti.com>
+
+commit 9ea359f7314132cbcb5a502d2d8ef095be1f45e4 upstream.
+
+According to I2C specification the NACK should be handled as follows:
+"When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
+Acknowledge signal. The master can then generate either a STOP condition to
+abort the transfer, or a repeated START condition to start a new transfer."
+[I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf]
+
+Currently the Davinci i2c driver interrupts the transfer on receipt of a
+NACK but fails to send a STOP in some situations and so makes the bus
+stuck until next I2C IP reset (idle/enable).
+
+For example, the issue will happen during SMBus read transfer which
+consists from two i2c messages write command/address and read data:
+
+S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P
+<--- write -----------------------> <--- read --------------------->
+
+The I2C client device will send NACK if it can't recognize "Command Code"
+and it's expected from I2C master to generate STP in this case.
+But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will
+not be generated.
+
+Hence, fix it by generating Stop condition (STP) always when NACK is received.
+
+This patch fixes Davinci I2C in the same way it was done for OMAP I2C
+commit cda2109a26eb ("i2c: omap: query STP always when NACK is received").
+
+Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Reported-by: Hein Tibosch <hein_tibosch@yahoo.es>
+Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-davinci.c |    8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-davinci.c
++++ b/drivers/i2c/busses/i2c-davinci.c
+@@ -414,11 +414,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter
+       if (dev->cmd_err & DAVINCI_I2C_STR_NACK) {
+               if (msg->flags & I2C_M_IGNORE_NAK)
+                       return msg->len;
+-              if (stop) {
+-                      w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+-                      w |= DAVINCI_I2C_MDR_STP;
+-                      davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w);
+-              }
++              w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
++              w |= DAVINCI_I2C_MDR_STP;
++              davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w);
+               return -EREMOTEIO;
+       }
+       return -EIO;
diff --git a/queue-3.10/i2c-omap-fix-i207-errata-handling.patch b/queue-3.10/i2c-omap-fix-i207-errata-handling.patch
new file mode 100644 (file)
index 0000000..ee610a6
--- /dev/null
@@ -0,0 +1,53 @@
+From ccfc866356674cb3a61829d239c685af6e85f197 Mon Sep 17 00:00:00 2001
+From: Alexander Kochetkov <al.kochet@gmail.com>
+Date: Fri, 21 Nov 2014 04:16:51 +0400
+Subject: i2c: omap: fix i207 errata handling
+
+From: Alexander Kochetkov <al.kochet@gmail.com>
+
+commit ccfc866356674cb3a61829d239c685af6e85f197 upstream.
+
+commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR
+and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
+Set) get handled. 6d9939f6514 code doesn't correspond to workaround provided by
+errata.
+
+According to errata ISR must filter out spurious RDR before data read not after.
+ISR must read RXSTAT to get number of bytes available to read. Because RDR
+could be set while there could no data in the receive FIFO.
+
+Restored pre 6d9939f6514 way of handling errata.
+
+Found by code review. Real impact haven't seen.
+Tested on Beagleboard XM C.
+
+Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
+Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY
+Tested-by: Felipe Balbi <balbi@ti.com>
+Reviewed-by: Felipe Balbi <balbi@ti.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-omap.c |    8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-omap.c
++++ b/drivers/i2c/busses/i2c-omap.c
+@@ -958,11 +958,13 @@ omap_i2c_isr_thread(int this_irq, void *
+                       if (dev->fifo_size)
+                               num_bytes = dev->buf_len;
+-                      omap_i2c_receive_data(dev, num_bytes, true);
+-
+-                      if (dev->errata & I2C_OMAP_ERRATA_I207)
++                      if (dev->errata & I2C_OMAP_ERRATA_I207) {
+                               i2c_omap_errata_i207(dev, stat);
++                              num_bytes = (omap_i2c_read_reg(dev,
++                                      OMAP_I2C_BUFSTAT_REG) >> 8) & 0x3F;
++                      }
++                      omap_i2c_receive_data(dev, num_bytes, true);
+                       omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+                       continue;
+               }
diff --git a/queue-3.10/i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch b/queue-3.10/i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch
new file mode 100644 (file)
index 0000000..250679a
--- /dev/null
@@ -0,0 +1,70 @@
+From 27caca9d2e01c92b26d0690f065aad093fea01c7 Mon Sep 17 00:00:00 2001
+From: Alexander Kochetkov <al.kochet@gmail.com>
+Date: Tue, 18 Nov 2014 21:00:58 +0400
+Subject: i2c: omap: fix NACK and Arbitration Lost irq handling
+
+From: Alexander Kochetkov <al.kochet@gmail.com>
+
+commit 27caca9d2e01c92b26d0690f065aad093fea01c7 upstream.
+
+commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)
+changed the interrupt handler to complete transfers without clearing
+XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
+fired again. As a result, ISR keep processing transfer after it was already
+complete (from the driver code point of view).
+
+A didn't see real impacts of the 1d7afc9, but it is really bad idea to
+have ISR running on user data after transfer was complete.
+
+It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be
+handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).
+
+According to specs (if I understood correctly), in case of NACK and AL driver
+must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
+NACK, AL, ARDY, and XDR (Master Transmitter Mode).
+
+All that is done down the code under the if condition:
+if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...
+
+The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so
+no interrupts is fired after ISR informs the rest of driver what transfer
+complete.
+
+Note: instead of removing break under NACK case, we could just replace 'break'
+with 'continue' and allow NACK transfer to finish using ARDY event. I found
+that NACK and ARDY bits usually set together. That case confirm TI wiki:
+http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK
+
+In order if someone interested in the event traces for NACK and AL cases,
+I sent them to mailing list.
+
+Tested on Beagleboard XM C.
+
+Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
+Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
+Acked-by: Felipe Balbi <balbi@ti.com>
+Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-omap.c |    2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-omap.c
++++ b/drivers/i2c/busses/i2c-omap.c
+@@ -928,14 +928,12 @@ omap_i2c_isr_thread(int this_irq, void *
+               if (stat & OMAP_I2C_STAT_NACK) {
+                       err |= OMAP_I2C_STAT_NACK;
+                       omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+-                      break;
+               }
+               if (stat & OMAP_I2C_STAT_AL) {
+                       dev_err(dev->dev, "Arbitration lost\n");
+                       err |= OMAP_I2C_STAT_AL;
+                       omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
+-                      break;
+               }
+               /*
diff --git a/queue-3.10/media-smiapp-only-some-selection-targets-are-settable.patch b/queue-3.10/media-smiapp-only-some-selection-targets-are-settable.patch
new file mode 100644 (file)
index 0000000..b7645a3
--- /dev/null
@@ -0,0 +1,33 @@
+From b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 Mon Sep 17 00:00:00 2001
+From: Sakari Ailus <sakari.ailus@iki.fi>
+Date: Thu, 6 Nov 2014 17:49:45 -0300
+Subject: media: smiapp: Only some selection targets are settable
+
+From: Sakari Ailus <sakari.ailus@iki.fi>
+
+commit b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 upstream.
+
+Setting a non-settable selection target caused BUG() to be called. The check
+for valid selections only takes the selection target into account, but does
+not tell whether it may be set, or only get. Fix the issue by simply
+returning an error to the user.
+
+Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/i2c/smiapp/smiapp-core.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/i2c/smiapp/smiapp-core.c
++++ b/drivers/media/i2c/smiapp/smiapp-core.c
+@@ -2139,7 +2139,7 @@ static int smiapp_set_selection(struct v
+               ret = smiapp_set_compose(subdev, fh, sel);
+               break;
+       default:
+-              BUG();
++              ret = -EINVAL;
+       }
+       mutex_unlock(&sensor->mutex);
diff --git a/queue-3.10/mm-fix-swapoff-hang-after-page-migration-and-fork.patch b/queue-3.10/mm-fix-swapoff-hang-after-page-migration-and-fork.patch
new file mode 100644 (file)
index 0000000..81c4d44
--- /dev/null
@@ -0,0 +1,70 @@
+From 2022b4d18a491a578218ce7a4eca8666db895a73 Mon Sep 17 00:00:00 2001
+From: Hugh Dickins <hughd@google.com>
+Date: Tue, 2 Dec 2014 15:59:39 -0800
+Subject: mm: fix swapoff hang after page migration and fork
+
+From: Hugh Dickins <hughd@google.com>
+
+commit 2022b4d18a491a578218ce7a4eca8666db895a73 upstream.
+
+I've been seeing swapoff hangs in recent testing: it's cycling around
+trying unsuccessfully to find an mm for some remaining pages of swap.
+
+I have been exercising swap and page migration more heavily recently,
+and now notice a long-standing error in copy_one_pte(): it's trying to
+add dst_mm to swapoff's mmlist when it finds a swap entry, but is doing
+so even when it's a migration entry or an hwpoison entry.
+
+Which wouldn't matter much, except it adds dst_mm next to src_mm,
+assuming src_mm is already on the mmlist: which may not be so.  Then if
+pages are later swapped out from dst_mm, swapoff won't be able to find
+where to replace them.
+
+There's already a !non_swap_entry() test for stats: move that up before
+the swap_duplicate() and the addition to mmlist.
+
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Cc: Kelley Nielsen <kelleynnn@gmail.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/memory.c |   24 ++++++++++++------------
+ 1 file changed, 12 insertions(+), 12 deletions(-)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -834,20 +834,20 @@ copy_one_pte(struct mm_struct *dst_mm, s
+               if (!pte_file(pte)) {
+                       swp_entry_t entry = pte_to_swp_entry(pte);
+-                      if (swap_duplicate(entry) < 0)
+-                              return entry.val;
++                      if (likely(!non_swap_entry(entry))) {
++                              if (swap_duplicate(entry) < 0)
++                                      return entry.val;
+-                      /* make sure dst_mm is on swapoff's mmlist. */
+-                      if (unlikely(list_empty(&dst_mm->mmlist))) {
+-                              spin_lock(&mmlist_lock);
+-                              if (list_empty(&dst_mm->mmlist))
+-                                      list_add(&dst_mm->mmlist,
+-                                               &src_mm->mmlist);
+-                              spin_unlock(&mmlist_lock);
+-                      }
+-                      if (likely(!non_swap_entry(entry)))
++                              /* make sure dst_mm is on swapoff's mmlist. */
++                              if (unlikely(list_empty(&dst_mm->mmlist))) {
++                                      spin_lock(&mmlist_lock);
++                                      if (list_empty(&dst_mm->mmlist))
++                                              list_add(&dst_mm->mmlist,
++                                                       &src_mm->mmlist);
++                                      spin_unlock(&mmlist_lock);
++                              }
+                               rss[MM_SWAPENTS]++;
+-                      else if (is_migration_entry(entry)) {
++                      } else if (is_migration_entry(entry)) {
+                               page = migration_entry_to_page(entry);
+                               if (PageAnon(page))
diff --git a/queue-3.10/mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch b/queue-3.10/mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch
new file mode 100644 (file)
index 0000000..f6f4bff
--- /dev/null
@@ -0,0 +1,50 @@
+From fb993fa1a2f669215fa03a09eed7848f2663e336 Mon Sep 17 00:00:00 2001
+From: Weijie Yang <weijie.yang@samsung.com>
+Date: Tue, 2 Dec 2014 15:59:25 -0800
+Subject: mm: frontswap: invalidate expired data on a dup-store failure
+
+From: Weijie Yang <weijie.yang@samsung.com>
+
+commit fb993fa1a2f669215fa03a09eed7848f2663e336 upstream.
+
+If a frontswap dup-store failed, it should invalidate the expired page
+in the backend, or it could trigger some data corruption issue.
+Such as:
+ 1. use zswap as the frontswap backend with writeback feature
+ 2. store a swap page(version_1) to entry A, success
+ 3. dup-store a newer page(version_2) to the same entry A, fail
+ 4. use __swap_writepage() write version_2 page to swapfile, success
+ 5. zswap do shrink, writeback version_1 page to swapfile
+ 6. version_2 page is overwrited by version_1, data corrupt.
+
+This patch fixes this issue by invalidating expired data immediately
+when meet a dup-store failure.
+
+Signed-off-by: Weijie Yang <weijie.yang@samsung.com>
+Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Cc: Seth Jennings <sjennings@variantweb.net>
+Cc: Dan Streetman <ddstreet@ieee.org>
+Cc: Minchan Kim <minchan@kernel.org>
+Cc: Bob Liu <bob.liu@oracle.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/frontswap.c |    4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/mm/frontswap.c
++++ b/mm/frontswap.c
+@@ -244,8 +244,10 @@ int __frontswap_store(struct page *page)
+                 the (older) page from frontswap
+                */
+               inc_frontswap_failed_stores();
+-              if (dup)
++              if (dup) {
+                       __frontswap_clear(sis, offset);
++                      frontswap_ops->invalidate_page(type, offset);
++              }
+       }
+       if (frontswap_writethrough_enabled)
+               /* report failure so swap also writes to swap device */
diff --git a/queue-3.10/series b/queue-3.10/series
new file mode 100644 (file)
index 0000000..b2dad68
--- /dev/null
@@ -0,0 +1,9 @@
+mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch
+mm-fix-swapoff-hang-after-page-migration-and-fork.patch
+xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch
+i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch
+i2c-omap-fix-i207-errata-handling.patch
+i2c-davinci-generate-stp-always-when-nack-is-received.patch
+drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch
+drm-i915-unlock-panel-even-when-lvds-is-disabled.patch
+media-smiapp-only-some-selection-targets-are-settable.patch
diff --git a/queue-3.10/xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch b/queue-3.10/xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch
new file mode 100644 (file)
index 0000000..7335b8b
--- /dev/null
@@ -0,0 +1,48 @@
+From 8d609725d4357f499e2103e46011308b32f53513 Mon Sep 17 00:00:00 2001
+From: Seth Forshee <seth.forshee@canonical.com>
+Date: Tue, 25 Nov 2014 20:28:24 -0600
+Subject: xen-netfront: Remove BUGs on paged skb data which crosses a page boundary
+
+From: Seth Forshee <seth.forshee@canonical.com>
+
+commit 8d609725d4357f499e2103e46011308b32f53513 upstream.
+
+These BUGs can be erroneously triggered by frags which refer to
+tail pages within a compound page. The data in these pages may
+overrun the hardware page while still being contained within the
+compound page, but since compound_order() evaluates to 0 for tail
+pages the assertion fails. The code already iterates through
+subsequent pages correctly in this scenario, so the BUGs are
+unnecessary and can be removed.
+
+Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
+Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
+Reviewed-by: David Vrabel <david.vrabel@citrix.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/xen-netfront.c |    5 -----
+ 1 file changed, 5 deletions(-)
+
+--- a/drivers/net/xen-netfront.c
++++ b/drivers/net/xen-netfront.c
+@@ -459,9 +459,6 @@ static void xennet_make_frags(struct sk_
+               len = skb_frag_size(frag);
+               offset = frag->page_offset;
+-              /* Data must not cross a page boundary. */
+-              BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
+-
+               /* Skip unused frames from start of page */
+               page += offset >> PAGE_SHIFT;
+               offset &= ~PAGE_MASK;
+@@ -469,8 +466,6 @@ static void xennet_make_frags(struct sk_
+               while (len > 0) {
+                       unsigned long bytes;
+-                      BUG_ON(offset >= PAGE_SIZE);
+-
+                       bytes = PAGE_SIZE - offset;
+                       if (bytes > len)
+                               bytes = len;
diff --git a/queue-3.14/series b/queue-3.14/series
new file mode 100644 (file)
index 0000000..7f6bc4f
--- /dev/null
@@ -0,0 +1,11 @@
+mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch
+mm-vmpressure.c-fix-race-in-vmpressure_work_fn.patch
+mm-fix-swapoff-hang-after-page-migration-and-fork.patch
+mm-fix-anon_vma_clone-error-treatment.patch
+xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch
+i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch
+i2c-omap-fix-i207-errata-handling.patch
+i2c-davinci-generate-stp-always-when-nack-is-received.patch
+drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch
+drm-i915-more-cautious-with-pch-fifo-underruns.patch
+drm-i915-unlock-panel-even-when-lvds-is-disabled.patch
diff --git a/queue-3.17/series b/queue-3.17/series
new file mode 100644 (file)
index 0000000..6732429
--- /dev/null
@@ -0,0 +1,19 @@
+mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch
+mm-vmpressure.c-fix-race-in-vmpressure_work_fn.patch
+drivers-input-evdev.c-don-t-kfree-a-vmalloc-address.patch
+fat-fix-oops-on-corrupted-vfat-fs.patch
+mm-fix-swapoff-hang-after-page-migration-and-fork.patch
+mm-fix-anon_vma_clone-error-treatment.patch
+slab-fix-nodeid-bounds-check-for-non-contiguous-node-ids.patch
+xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch
+drm-nouveau-gf116-remove-copy1-engine.patch
+nouveau-move-the-hotplug-ignore-to-correct-place.patch
+i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch
+i2c-omap-fix-i207-errata-handling.patch
+i2c-davinci-generate-stp-always-when-nack-is-received.patch
+i2c-cadence-set-the-hardware-time-out-register-to-maximum-value.patch
+drm-radeon-ignore-radeon_gem_gtt_wc-on-32-bit-x86.patch
+drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch
+of-fdt-memblock_reserve-memreserve-regions-in-the-case-of-partial-overlap.patch
+drm-i915-more-cautious-with-pch-fifo-underruns.patch
+drm-i915-unlock-panel-even-when-lvds-is-disabled.patch