--- /dev/null
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Sun, 15 Apr 2012 11:56:03 +0100
+Subject: drm/i915: Refactor the deferred PM_IIR handling into a single function
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit fc6826d1dcd65f3d1e9a5377678882e4e08f02be upstream.
+
+This function, along with the registers and deferred work hander, are
+all shared with SandyBridge, IvyBridge and their variants. So remove the
+duplicate code into a single function.
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
+Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+[bwh: Backported to 3.2: adjust context; drop changes for Valley View]
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/i915_irq.c | 58 ++++++++++++++++++++--------------------
+ 1 file changed, 29 insertions(+), 29 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_irq.c
++++ b/drivers/gpu/drm/i915/i915_irq.c
+@@ -424,6 +424,31 @@ static void gen6_pm_rps_work(struct work
+ mutex_unlock(&dev_priv->dev->struct_mutex);
+ }
+
++static void gen6_queue_rps_work(struct drm_i915_private *dev_priv,
++ u32 pm_iir)
++{
++ unsigned long flags;
++
++ /*
++ * IIR bits should never already be set because IMR should
++ * prevent an interrupt from being shown in IIR. The warning
++ * displays a case where we've unsafely cleared
++ * dev_priv->pm_iir. Although missing an interrupt of the same
++ * type is not a problem, it displays a problem in the logic.
++ *
++ * The mask bit in IMR is cleared by rps_work.
++ */
++
++ spin_lock_irqsave(&dev_priv->rps_lock, flags);
++ WARN(dev_priv->pm_iir & pm_iir, "Missed a PM interrupt\n");
++ dev_priv->pm_iir |= pm_iir;
++ I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
++ POSTING_READ(GEN6_PMIMR);
++ spin_unlock_irqrestore(&dev_priv->rps_lock, flags);
++
++ queue_work(dev_priv->wq, &dev_priv->rps_work);
++}
++
+ static void pch_irq_handler(struct drm_device *dev, u32 pch_iir)
+ {
+ drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
+@@ -529,16 +554,8 @@ static irqreturn_t ivybridge_irq_handler
+ pch_irq_handler(dev, pch_iir);
+ }
+
+- if (pm_iir & GEN6_PM_DEFERRED_EVENTS) {
+- unsigned long flags;
+- spin_lock_irqsave(&dev_priv->rps_lock, flags);
+- WARN(dev_priv->pm_iir & pm_iir, "Missed a PM interrupt\n");
+- dev_priv->pm_iir |= pm_iir;
+- I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
+- POSTING_READ(GEN6_PMIMR);
+- spin_unlock_irqrestore(&dev_priv->rps_lock, flags);
+- queue_work(dev_priv->wq, &dev_priv->rps_work);
+- }
++ if (pm_iir & GEN6_PM_DEFERRED_EVENTS)
++ gen6_queue_rps_work(dev_priv, pm_iir);
+
+ /* should clear PCH hotplug event before clear CPU irq */
+ I915_WRITE(SDEIIR, pch_iir);
+@@ -634,25 +651,8 @@ static irqreturn_t ironlake_irq_handler(
+ i915_handle_rps_change(dev);
+ }
+
+- if (IS_GEN6(dev) && pm_iir & GEN6_PM_DEFERRED_EVENTS) {
+- /*
+- * IIR bits should never already be set because IMR should
+- * prevent an interrupt from being shown in IIR. The warning
+- * displays a case where we've unsafely cleared
+- * dev_priv->pm_iir. Although missing an interrupt of the same
+- * type is not a problem, it displays a problem in the logic.
+- *
+- * The mask bit in IMR is cleared by rps_work.
+- */
+- unsigned long flags;
+- spin_lock_irqsave(&dev_priv->rps_lock, flags);
+- WARN(dev_priv->pm_iir & pm_iir, "Missed a PM interrupt\n");
+- dev_priv->pm_iir |= pm_iir;
+- I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
+- POSTING_READ(GEN6_PMIMR);
+- spin_unlock_irqrestore(&dev_priv->rps_lock, flags);
+- queue_work(dev_priv->wq, &dev_priv->rps_work);
+- }
++ if (IS_GEN6(dev) && pm_iir & GEN6_PM_DEFERRED_EVENTS)
++ gen6_queue_rps_work(dev_priv, pm_iir);
+
+ /* should clear PCH hotplug event before clear CPU irq */
+ I915_WRITE(SDEIIR, pch_iir);
--- /dev/null
+From 58bf8062d0b293b8e1028e5b0342082002886bd4 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Thu, 21 Jun 2012 14:55:22 +0200
+Subject: drm/i915: rip out the PM_IIR WARN
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 58bf8062d0b293b8e1028e5b0342082002886bd4 upstream.
+
+After banging my head against this for the past few months, I still
+don't see how this could possible race under the premise that once an
+irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again
+until we unmask it in PM_IMR.
+
+Still, we have reports of this being seen in the wild. Now Bspec has
+this little bit of lovely language in the PMIIR register:
+
+Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR":
+
+"For each bit, the IIR can store a second pending interrupt if two or
+more of the same interrupt conditions occur before the first condition
+is cleared. Upon clearing the interrupt, the IIR bit will momentarily
+go low, then return high to indicate there is another interrupt
+pending."
+
+Now if we presume that PMIMR only prevent new interrupts from being
+queued, we could easily end up masking an interrupt and clearing it,
+but the 2nd pending interrupt setting the bit in PMIIR right away
+again. Which leads, the next time the irq handler runs, to hitting the
+WARN.
+
+Also, no bad side effects of this have ever been reported. And we've
+tracked down our issues with the gpu turbo getting stuck to bogus
+interrupt generation limits in th RPLIMIT register.
+
+So let's just rip out this WARN as bogus and call it a day. The only
+shallow thing here is that this 2-deep irq queue in the hw makes you
+wonder how racy the windows irq handler is ...
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907
+Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_irq.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_irq.c
++++ b/drivers/gpu/drm/i915/i915_irq.c
+@@ -440,7 +440,6 @@ static void gen6_queue_rps_work(struct d
+ */
+
+ spin_lock_irqsave(&dev_priv->rps_lock, flags);
+- WARN(dev_priv->pm_iir & pm_iir, "Missed a PM interrupt\n");
+ dev_priv->pm_iir |= pm_iir;
+ I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
+ POSTING_READ(GEN6_PMIMR);
--- /dev/null
+From: majianpeng <majianpeng@gmail.com>
+Date: Tue, 12 Jun 2012 08:31:10 +0800
+Subject: md/raid5: Do not add data_offset before call to is_badblock
+
+From: majianpeng <majianpeng@gmail.com>
+
+commit 6c0544e255dd6582a9899572e120fb55d9f672a4 upstream.
+
+In chunk_aligned_read() we are adding data_offset before calling
+is_badblock. But is_badblock also adds data_offset, so that is bad.
+
+So move the addition of data_offset to after the call to
+is_badblock.
+
+This bug was introduced by commit 31c176ecdf3563140e639
+ md/raid5: avoid reading from known bad blocks.
+which first appeared in 3.0. So that patch is suitable for any
+-stable kernel from 3.0.y onwards. However it will need minor
+revision for most of those (as the comment didn't appear until
+recently).
+
+Signed-off-by: majianpeng <majianpeng@gmail.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+[bwh: Backported to 3.2: ignored missing comment]
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/raid5.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -3850,7 +3850,6 @@ static int chunk_aligned_read(struct mdd
+ raid_bio->bi_next = (void*)rdev;
+ align_bi->bi_bdev = rdev->bdev;
+ align_bi->bi_flags &= ~(1 << BIO_SEG_VALID);
+- align_bi->bi_sector += rdev->data_offset;
+
+ if (!bio_fits_rdev(align_bi) ||
+ is_badblock(rdev, align_bi->bi_sector, align_bi->bi_size>>9,
+@@ -3861,6 +3860,9 @@ static int chunk_aligned_read(struct mdd
+ return 0;
+ }
+
++ /* No reshape active, so we can trust rdev->data_offset */
++ align_bi->bi_sector += rdev->data_offset;
++
+ spin_lock_irq(&conf->device_lock);
+ wait_event_lock_irq(conf->wait_for_stripe,
+ conf->quiesce == 0,
--- /dev/null
+From: Andy Lutomirski <luto@amacapital.net>
+Date: Thu, 5 Jul 2012 16:00:11 -0700
+Subject: mm: Hold a file reference in madvise_remove
+
+From: Andy Lutomirski <luto@amacapital.net>
+
+commit 9ab4233dd08036fe34a89c7dc6f47a8bf2eb29eb upstream.
+
+Otherwise the code races with munmap (causing a use-after-free
+of the vma) or with close (causing a use-after-free of the struct
+file).
+
+The bug was introduced by commit 90ed52ebe481 ("[PATCH] holepunch: fix
+mmap_sem i_mutex deadlock")
+
+Cc: Hugh Dickins <hugh@veritas.com>
+Cc: Miklos Szeredi <mszeredi@suse.cz>
+Cc: Badari Pulavarty <pbadari@us.ibm.com>
+Cc: Nick Piggin <npiggin@suse.de>
+Signed-off-by: Andy Lutomirski <luto@amacapital.net>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+[bwh: Backported to 3.2:
+ - Adjust context
+ - madvise_remove() calls vmtruncate_range(), not do_fallocate()]
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/madvise.c | 16 +++++++++++++---
+ 1 file changed, 13 insertions(+), 3 deletions(-)
+
+--- a/mm/madvise.c
++++ b/mm/madvise.c
+@@ -13,6 +13,7 @@
+ #include <linux/hugetlb.h>
+ #include <linux/sched.h>
+ #include <linux/ksm.h>
++#include <linux/file.h>
+
+ /*
+ * Any behaviour which results in changes to the vma->vm_flags needs to
+@@ -203,14 +204,16 @@ static long madvise_remove(struct vm_are
+ struct address_space *mapping;
+ loff_t offset, endoff;
+ int error;
++ struct file *f;
+
+ *prev = NULL; /* tell sys_madvise we drop mmap_sem */
+
+ if (vma->vm_flags & (VM_LOCKED|VM_NONLINEAR|VM_HUGETLB))
+ return -EINVAL;
+
+- if (!vma->vm_file || !vma->vm_file->f_mapping
+- || !vma->vm_file->f_mapping->host) {
++ f = vma->vm_file;
++
++ if (!f || !f->f_mapping || !f->f_mapping->host) {
+ return -EINVAL;
+ }
+
+@@ -224,9 +227,16 @@ static long madvise_remove(struct vm_are
+ endoff = (loff_t)(end - vma->vm_start - 1)
+ + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
+
+- /* vmtruncate_range needs to take i_mutex */
++ /*
++ * vmtruncate_range may need to take i_mutex. We need to
++ * explicitly grab a reference because the vma (and hence the
++ * vma's reference to the file) can go away as soon as we drop
++ * mmap_sem.
++ */
++ get_file(f);
+ up_read(¤t->mm->mmap_sem);
+ error = vmtruncate_range(mapping->host, offset, endoff);
++ fput(f);
+ down_read(¤t->mm->mmap_sem);
+ return error;
+ }
macvtap-zerocopy-validate-vectors-before-building-skb.patch
net-wireless-ipw2x00-add-supported-cipher-suites-to-wiphy-initialization.patch
splice-fix-racy-pipe-buffers-uses.patch
+drm-i915-refactor-the-deferred-pm_iir-handling-into-a-single.patch
+drm-i915-rip-out-the-pm_iir-warn.patch
+mm-hold-a-file-reference-in-madvise_remove.patch
+md-raid5-do-not-add-data_offset-before-call-to-is_badblock.patch
+staging-iio-ad7606-re-add-missing-scale-attribute.patch
--- /dev/null
+From 279bf2e57c30c9a4482b2b6ede11b31c41e35e78 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Tue, 5 Jun 2012 18:16:31 +0200
+Subject: staging:iio:ad7606: Re-add missing scale attribute
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 279bf2e57c30c9a4482b2b6ede11b31c41e35e78 upstream.
+
+Commit 50ac23be ("staging:iio:adc:ad7606 add local define for chan_spec
+structures.") accidentally removed the scale info_mask flag. This patch
+adds it back again.
+
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Acked-by: Jonathan Cameron <jic23@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+[herton: Backported to 3.4: info_mask was not used yet with another flag]
+Signed-off-by: Herton R. Krzesinski <herton@canonical.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/iio/adc/ad7606_core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/staging/iio/adc/ad7606_core.c
++++ b/drivers/staging/iio/adc/ad7606_core.c
+@@ -235,6 +235,7 @@ static const struct attribute_group ad76
+ .indexed = 1, \
+ .channel = num, \
+ .address = num, \
++ .info_mask = IIO_CHAN_INFO_SCALE_SHARED_BIT, \
+ .scan_index = num, \
+ .scan_type = IIO_ST('s', 16, 16, 0), \
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
