--- /dev/null
+From 274252862f386b7868f35bf5ceaa5391a8ccfdf3 Mon Sep 17 00:00:00 2001
+From: Phil Sutter <phil.sutter@viprinet.com>
+Date: Wed, 16 Nov 2011 18:28:01 +0100
+Subject: crypto: mv_cesa - fix hashing of chunks > 1920 bytes
+
+From: Phil Sutter <phil.sutter@viprinet.com>
+
+commit 274252862f386b7868f35bf5ceaa5391a8ccfdf3 upstream.
+
+This was broken by commit 7759995c75ae0cbd4c861582908449f6b6208e7a (yes,
+myself). The basic problem here is since the digest state is only saved
+after the last chunk, the state array is only valid when handling the
+first chunk of the next buffer. Broken since linux-3.0.
+
+Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/crypto/mv_cesa.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/crypto/mv_cesa.c
++++ b/drivers/crypto/mv_cesa.c
+@@ -342,11 +342,13 @@ static void mv_process_hash_current(int
+ else
+ op.config |= CFG_MID_FRAG;
+
+- writel(req_ctx->state[0], cpg->reg + DIGEST_INITIAL_VAL_A);
+- writel(req_ctx->state[1], cpg->reg + DIGEST_INITIAL_VAL_B);
+- writel(req_ctx->state[2], cpg->reg + DIGEST_INITIAL_VAL_C);
+- writel(req_ctx->state[3], cpg->reg + DIGEST_INITIAL_VAL_D);
+- writel(req_ctx->state[4], cpg->reg + DIGEST_INITIAL_VAL_E);
++ if (first_block) {
++ writel(req_ctx->state[0], cpg->reg + DIGEST_INITIAL_VAL_A);
++ writel(req_ctx->state[1], cpg->reg + DIGEST_INITIAL_VAL_B);
++ writel(req_ctx->state[2], cpg->reg + DIGEST_INITIAL_VAL_C);
++ writel(req_ctx->state[3], cpg->reg + DIGEST_INITIAL_VAL_D);
++ writel(req_ctx->state[4], cpg->reg + DIGEST_INITIAL_VAL_E);
++ }
+ }
+
+ memcpy(cpg->sram + SRAM_CONFIG, &op, sizeof(struct sec_accel_config));
--- /dev/null
+From cb0e093162d7b6589c2217a00e2abfef686b32d6 Mon Sep 17 00:00:00 2001
+From: Jesse Barnes <jbarnes@virtuousgeek.org>
+Date: Thu, 28 Jul 2011 14:50:30 -0700
+Subject: drm/i915: fix CB tuning check for ILK+
+
+From: Jesse Barnes <jbarnes@virtuousgeek.org>
+
+commit cb0e093162d7b6589c2217a00e2abfef686b32d6 upstream.
+
+CB tuning is needed to handle potential process variations that might
+cause clock jitter for certain PLL settings. However, we were setting
+it incorrectly since we were using the wrong M value as a check (M1 when
+we needed to use the whole M value). Fix it up, making my HDMI
+attached display a little prettier (used to have occasional dots crawl
+across the display).
+
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Keith Packard <keithp@keithp.com>
+Signed-off-by: Timo Aaltonen <timo@canonical.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/intel_display.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -4972,7 +4972,7 @@ static int ironlake_crtc_mode_set(struct
+ } else if (is_sdvo && is_tv)
+ factor = 20;
+
+- if (clock.m1 < factor * clock.n)
++ if (clock.m < factor * clock.n)
+ fp |= FP_CB_TUNE;
+
+ dpll = 0;
--- /dev/null
+From 775d17b6ca4357048f36c22151335addfe15db4b Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Sun, 9 Oct 2011 21:52:01 +0200
+Subject: drm/i915: Ivybridge still has fences!
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 775d17b6ca4357048f36c22151335addfe15db4b upstream.
+
+So don't forget to restore them on resume and dump them into
+the error state.
+
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Keith Packard <keithp@keithp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/i915_irq.c | 1 +
+ drivers/gpu/drm/i915/i915_suspend.c | 2 ++
+ 2 files changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_irq.c
++++ b/drivers/gpu/drm/i915/i915_irq.c
+@@ -820,6 +820,7 @@ static void i915_gem_record_fences(struc
+
+ /* Fences */
+ switch (INTEL_INFO(dev)->gen) {
++ case 7:
+ case 6:
+ for (i = 0; i < 16; i++)
+ error->fence[i] = I915_READ64(FENCE_REG_SANDYBRIDGE_0 + (i * 8));
+--- a/drivers/gpu/drm/i915/i915_suspend.c
++++ b/drivers/gpu/drm/i915/i915_suspend.c
+@@ -370,6 +370,7 @@ static void i915_save_modeset_reg(struct
+
+ /* Fences */
+ switch (INTEL_INFO(dev)->gen) {
++ case 7:
+ case 6:
+ for (i = 0; i < 16; i++)
+ dev_priv->saveFENCE[i] = I915_READ64(FENCE_REG_SANDYBRIDGE_0 + (i * 8));
+@@ -404,6 +405,7 @@ static void i915_restore_modeset_reg(str
+
+ /* Fences */
+ switch (INTEL_INFO(dev)->gen) {
++ case 7:
+ case 6:
+ for (i = 0; i < 16; i++)
+ I915_WRITE64(FENCE_REG_SANDYBRIDGE_0 + (i * 8), dev_priv->saveFENCE[i]);
--- /dev/null
+From 406478dc911e16677fbd9c84d1d50cdffbc031ab Mon Sep 17 00:00:00 2001
+From: Eric Anholt <eric@anholt.net>
+Date: Mon, 7 Nov 2011 16:07:04 -0800
+Subject: drm/i915: Turn on a required 3D clock gating bit on Sandybridge.
+
+From: Eric Anholt <eric@anholt.net>
+
+commit 406478dc911e16677fbd9c84d1d50cdffbc031ab upstream.
+
+Fixes rendering failures in Unigine Tropics and Sanctuary and the mesa
+"fire" demo.
+
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Keith Packard <keithp@keithp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/i915_reg.h | 3 +++
+ drivers/gpu/drm/i915/intel_display.c | 9 +++++++++
+ 2 files changed, 12 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_reg.h
++++ b/drivers/gpu/drm/i915/i915_reg.h
+@@ -3370,6 +3370,9 @@
+
+ #define GT_FIFO_FREE_ENTRIES 0x120008
+
++#define GEN6_UCGCTL2 0x9404
++# define GEN6_RCPBUNIT_CLOCK_GATE_DISABLE (1 << 12)
++
+ #define GEN6_RPNSWREQ 0xA008
+ #define GEN6_TURBO_DISABLE (1<<31)
+ #define GEN6_FREQUENCY(x) ((x)<<25)
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -7405,6 +7405,15 @@ static void gen6_init_clock_gating(struc
+ I915_WRITE(WM2_LP_ILK, 0);
+ I915_WRITE(WM1_LP_ILK, 0);
+
++ /* According to the BSpec vol1g, bit 12 (RCPBUNIT) clock
++ * gating disable must be set. Failure to set it results in
++ * flickering pixels due to Z write ordering failures after
++ * some amount of runtime in the Mesa "fire" demo, and Unigine
++ * Sanctuary and Tropics, and apparently anything else with
++ * alpha test or pixel discard.
++ */
++ I915_WRITE(GEN6_UCGCTL2, GEN6_RCPBUNIT_CLOCK_GATE_DISABLE);
++
+ /*
+ * According to the spec the following bits should be
+ * set in order to enable memory self-refresh and fbc:
--- /dev/null
+From 9ca1d10d748e56964de95e3ed80211b192f56cf4 Mon Sep 17 00:00:00 2001
+From: Eric Anholt <eric@anholt.net>
+Date: Mon, 7 Nov 2011 16:07:05 -0800
+Subject: drm/i915: Turn on another required clock gating bit on gen6.
+
+From: Eric Anholt <eric@anholt.net>
+
+commit 9ca1d10d748e56964de95e3ed80211b192f56cf4 upstream.
+
+Unlike the previous one, I don't have known testcases it fixes. I'd
+rather not go through the same debug cycle on whatever testcases those
+might be.
+
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Keith Packard <keithp@keithp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/i915_reg.h | 1 +
+ drivers/gpu/drm/i915/intel_display.c | 7 ++++++-
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_reg.h
++++ b/drivers/gpu/drm/i915/i915_reg.h
+@@ -3372,6 +3372,7 @@
+
+ #define GEN6_UCGCTL2 0x9404
+ # define GEN6_RCPBUNIT_CLOCK_GATE_DISABLE (1 << 12)
++# define GEN6_RCCUNIT_CLOCK_GATE_DISABLE (1 << 11)
+
+ #define GEN6_RPNSWREQ 0xA008
+ #define GEN6_TURBO_DISABLE (1<<31)
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -7411,8 +7411,13 @@ static void gen6_init_clock_gating(struc
+ * some amount of runtime in the Mesa "fire" demo, and Unigine
+ * Sanctuary and Tropics, and apparently anything else with
+ * alpha test or pixel discard.
++ *
++ * According to the spec, bit 11 (RCCUNIT) must also be set,
++ * but we didn't debug actual testcases to find it out.
+ */
+- I915_WRITE(GEN6_UCGCTL2, GEN6_RCPBUNIT_CLOCK_GATE_DISABLE);
++ I915_WRITE(GEN6_UCGCTL2,
++ GEN6_RCPBUNIT_CLOCK_GATE_DISABLE |
++ GEN6_RCCUNIT_CLOCK_GATE_DISABLE);
+
+ /*
+ * According to the spec the following bits should be
--- /dev/null
+From a5cd335165e31db9dbab636fd29895d41da55dd2 Mon Sep 17 00:00:00 2001
+From: Xi Wang <xi.wang@gmail.com>
+Date: Wed, 23 Nov 2011 01:12:01 -0500
+Subject: drm: integer overflow in drm_mode_dirtyfb_ioctl()
+
+From: Xi Wang <xi.wang@gmail.com>
+
+commit a5cd335165e31db9dbab636fd29895d41da55dd2 upstream.
+
+There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
+if userspace passes in a large num_clips. The call to kmalloc would
+allocate a small buffer, and the call to fb->funcs->dirty may result
+in a memory corruption.
+
+Reported-by: Haogang Chen <haogangchen@gmail.com>
+Signed-off-by: Xi Wang <xi.wang@gmail.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/drm_crtc.c | 4 ++++
+ include/drm/drm_mode.h | 2 ++
+ 2 files changed, 6 insertions(+)
+
+--- a/drivers/gpu/drm/drm_crtc.c
++++ b/drivers/gpu/drm/drm_crtc.c
+@@ -1866,6 +1866,10 @@ int drm_mode_dirtyfb_ioctl(struct drm_de
+ }
+
+ if (num_clips && clips_ptr) {
++ if (num_clips < 0 || num_clips > DRM_MODE_FB_DIRTY_MAX_CLIPS) {
++ ret = -EINVAL;
++ goto out_err1;
++ }
+ clips = kzalloc(num_clips * sizeof(*clips), GFP_KERNEL);
+ if (!clips) {
+ ret = -ENOMEM;
+--- a/include/drm/drm_mode.h
++++ b/include/drm/drm_mode.h
+@@ -233,6 +233,8 @@ struct drm_mode_fb_cmd {
+ #define DRM_MODE_FB_DIRTY_ANNOTATE_FILL 0x02
+ #define DRM_MODE_FB_DIRTY_FLAGS 0x03
+
++#define DRM_MODE_FB_DIRTY_MAX_CLIPS 256
++
+ /*
+ * Mark a region of a framebuffer as dirty.
+ *
--- /dev/null
+From d724502a9d7a46f4a56a1663b1f50d2dc9d1ef40 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Mon, 21 Nov 2011 12:10:14 -0500
+Subject: drm/radeon/kms: fix up gpio i2c mask bits for r4xx for real
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit d724502a9d7a46f4a56a1663b1f50d2dc9d1ef40 upstream.
+
+Fixes i2c test failures when i2c_algo_bit.bit_test=1.
+
+The hw doesn't actually require a mask, so just set it
+to the default mask bits for r1xx-r4xx radeon ddc.
+
+I missed this part the first time through.
+
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/radeon/radeon_atombios.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/radeon_atombios.c
++++ b/drivers/gpu/drm/radeon/radeon_atombios.c
+@@ -169,6 +169,18 @@ void radeon_atombios_i2c_init(struct rad
+ gpio = &i2c_info->asGPIO_Info[i];
+ i2c.valid = false;
+
++ /* r4xx mask is technically not used by the hw, so patch in the legacy mask bits */
++ if ((rdev->family == CHIP_R420) ||
++ (rdev->family == CHIP_R423) ||
++ (rdev->family == CHIP_RV410)) {
++ if ((le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x0018) ||
++ (le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x0019) ||
++ (le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x001a)) {
++ gpio->ucClkMaskShift = 0x19;
++ gpio->ucDataMaskShift = 0x18;
++ }
++ }
++
+ /* some evergreen boards have bad data for this entry */
+ if (ASIC_IS_DCE4(rdev)) {
+ if ((i == 7) &&
--- /dev/null
+From ff02b13f6867af72682d7a9bb9bd705f9af2bab0 Mon Sep 17 00:00:00 2001
+From: Ben Skeggs <bskeggs@redhat.com>
+Date: Wed, 14 Sep 2011 06:08:06 +1000
+Subject: drm/ttm: request zeroed system memory pages for new TT buffer objects
+
+From: Ben Skeggs <bskeggs@redhat.com>
+
+commit ff02b13f6867af72682d7a9bb9bd705f9af2bab0 upstream.
+
+Fixes an information leak to userspace, we were handing out un-zeroed pages
+for any newly created TTM_PL_TT buffer.
+
+Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Tested-by: Marcin Slusarz <marcin.slusarz@gmail.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/ttm/ttm_bo.c
++++ b/drivers/gpu/drm/ttm/ttm_bo.c
+@@ -394,7 +394,8 @@ static int ttm_bo_handle_move_mem(struct
+
+ if (!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED)) {
+ if (bo->ttm == NULL) {
+- ret = ttm_bo_add_ttm(bo, false);
++ bool zero = !(old_man->flags & TTM_MEMTYPE_FLAG_FIXED);
++ ret = ttm_bo_add_ttm(bo, zero);
+ if (ret)
+ goto out_err;
+ }
--- /dev/null
+From 0f751e641a71157aa584c2a2e22fda52b52b8a56 Mon Sep 17 00:00:00 2001
+From: Tyler Hicks <tyhicks@canonical.com>
+Date: Wed, 23 Nov 2011 11:31:24 -0600
+Subject: eCryptfs: Extend array bounds for all filename chars
+
+From: Tyler Hicks <tyhicks@canonical.com>
+
+commit 0f751e641a71157aa584c2a2e22fda52b52b8a56 upstream.
+
+From mhalcrow's original commit message:
+
+ Characters with ASCII values greater than the size of
+ filename_rev_map[] are valid filename characters.
+ ecryptfs_decode_from_filename() will access kernel memory beyond
+ that array, and ecryptfs_parse_tag_70_packet() will then decrypt
+ those characters. The attacker, using the FNEK of the crafted file,
+ can then re-encrypt the characters to reveal the kernel memory past
+ the end of the filename_rev_map[] array. I expect low security
+ impact since this array is statically allocated in the text area,
+ and the amount of memory past the array that is accessible is
+ limited by the largest possible ASCII filename character.
+
+This patch solves the issue reported by mhalcrow but with an
+implementation suggested by Linus to simply extend the length of
+filename_rev_map[] to 256. Characters greater than 0x7A are mapped to
+0x00, which is how invalid characters less than 0x7A were previously
+being handled.
+
+Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
+Reported-by: Michael Halcrow <mhalcrow@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/ecryptfs/crypto.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/ecryptfs/crypto.c
++++ b/fs/ecryptfs/crypto.c
+@@ -1943,7 +1943,7 @@ static unsigned char *portable_filename_
+
+ /* We could either offset on every reverse map or just pad some 0x00's
+ * at the front here */
+-static const unsigned char filename_rev_map[] = {
++static const unsigned char filename_rev_map[256] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 7 */
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 15 */
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 23 */
+@@ -1959,7 +1959,7 @@ static const unsigned char filename_rev_
+ 0x00, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, /* 103 */
+ 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x33, 0x34, /* 111 */
+ 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, /* 119 */
+- 0x3D, 0x3E, 0x3F
++ 0x3D, 0x3E, 0x3F /* 123 - 255 initialized to 0x00 */
+ };
+
+ /**
--- /dev/null
+From 32001d6fe9ac6b0423e674a3093aa56740849f3b Mon Sep 17 00:00:00 2001
+From: Tyler Hicks <tyhicks@canonical.com>
+Date: Mon, 21 Nov 2011 17:31:29 -0600
+Subject: eCryptfs: Flush file in vma close
+
+From: Tyler Hicks <tyhicks@canonical.com>
+
+commit 32001d6fe9ac6b0423e674a3093aa56740849f3b upstream.
+
+Dirty pages weren't being written back when an mmap'ed eCryptfs file was
+closed before the mapping was unmapped. Since f_ops->flush() is not
+called by the munmap() path, the lower file was simply being released.
+This patch flushes the eCryptfs file in the vm_ops->close() path.
+
+https://launchpad.net/bugs/870326
+
+Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/ecryptfs/file.c | 23 ++++++++++++++++++++++-
+ 1 file changed, 22 insertions(+), 1 deletion(-)
+
+--- a/fs/ecryptfs/file.c
++++ b/fs/ecryptfs/file.c
+@@ -139,6 +139,27 @@ out:
+ return rc;
+ }
+
++static void ecryptfs_vma_close(struct vm_area_struct *vma)
++{
++ filemap_write_and_wait(vma->vm_file->f_mapping);
++}
++
++static const struct vm_operations_struct ecryptfs_file_vm_ops = {
++ .close = ecryptfs_vma_close,
++ .fault = filemap_fault,
++};
++
++static int ecryptfs_file_mmap(struct file *file, struct vm_area_struct *vma)
++{
++ int rc;
++
++ rc = generic_file_mmap(file, vma);
++ if (!rc)
++ vma->vm_ops = &ecryptfs_file_vm_ops;
++
++ return rc;
++}
++
+ struct kmem_cache *ecryptfs_file_info_cache;
+
+ /**
+@@ -348,7 +369,7 @@ const struct file_operations ecryptfs_ma
+ #ifdef CONFIG_COMPAT
+ .compat_ioctl = ecryptfs_compat_ioctl,
+ #endif
+- .mmap = generic_file_mmap,
++ .mmap = ecryptfs_file_mmap,
+ .open = ecryptfs_open,
+ .flush = ecryptfs_flush,
+ .release = ecryptfs_release,
--- /dev/null
+From cc6bcf7d2ec2234e7b41770185e4dc826390185e Mon Sep 17 00:00:00 2001
+From: "Jeffrey (Sheng-Hui) Chu" <jeffchu@broadcom.com>
+Date: Wed, 23 Nov 2011 11:33:07 +0100
+Subject: i2c-algo-bit: Generate correct i2c address sequence for 10-bit target
+
+From: "Jeffrey (Sheng-Hui) Chu" <jeffchu@broadcom.com>
+
+commit cc6bcf7d2ec2234e7b41770185e4dc826390185e upstream.
+
+The wrong bits were put on the wire, fix that.
+
+This fixes kernel bug #42562.
+
+Signed-off-by: Sheng-Hui J. Chu <jeffchu@broadcom.com>
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/i2c/algos/i2c-algo-bit.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/i2c/algos/i2c-algo-bit.c
++++ b/drivers/i2c/algos/i2c-algo-bit.c
+@@ -486,7 +486,7 @@ static int bit_doAddress(struct i2c_adap
+
+ if (flags & I2C_M_TEN) {
+ /* a ten bit address */
+- addr = 0xf0 | ((msg->addr >> 7) & 0x03);
++ addr = 0xf0 | ((msg->addr >> 7) & 0x06);
+ bit_dbg(2, &i2c_adap->dev, "addr0: %d\n", addr);
+ /* try extended address code...*/
+ ret = try_address(i2c_adap, addr, retries);
+@@ -496,7 +496,7 @@ static int bit_doAddress(struct i2c_adap
+ return -EREMOTEIO;
+ }
+ /* the remaining 8 bit address */
+- ret = i2c_outb(i2c_adap, msg->addr & 0x7f);
++ ret = i2c_outb(i2c_adap, msg->addr & 0xff);
+ if ((ret != 1) && !nak_ok) {
+ /* the chip did not ack / xmission error occurred */
+ dev_err(&i2c_adap->dev, "died at 2nd address code\n");
--- /dev/null
+From 4cac2eb158c6da0c761689345c6cc5df788a6292 Mon Sep 17 00:00:00 2001
+From: Bjorn Helgaas <bhelgaas@google.com>
+Date: Tue, 23 Aug 2011 10:16:43 -0600
+Subject: PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+commit 4cac2eb158c6da0c761689345c6cc5df788a6292 upstream.
+
+Previously we claimed device ID 0x7450, regardless of the vendor, which is
+clearly wrong. Now we'll claim that device ID only for AMD.
+
+I suspect this was just a typo in the original code, but it's possible this
+change will break shpchp on non-7450 AMD bridges. If so, we'll have to fix
+them as we find them.
+
+Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863
+Reported-by: Ralf Jung <ralfjung-e@gmx.de>
+Cc: Joerg Roedel <joerg.roedel@amd.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/hotplug/shpchp_core.c | 4 ++--
+ drivers/pci/hotplug/shpchp_hpc.c | 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/pci/hotplug/shpchp_core.c
++++ b/drivers/pci/hotplug/shpchp_core.c
+@@ -278,8 +278,8 @@ static int get_adapter_status (struct ho
+
+ static int is_shpc_capable(struct pci_dev *dev)
+ {
+- if ((dev->vendor == PCI_VENDOR_ID_AMD) || (dev->device ==
+- PCI_DEVICE_ID_AMD_GOLAM_7450))
++ if (dev->vendor == PCI_VENDOR_ID_AMD &&
++ dev->device == PCI_DEVICE_ID_AMD_GOLAM_7450)
+ return 1;
+ if (!pci_find_capability(dev, PCI_CAP_ID_SHPC))
+ return 0;
+--- a/drivers/pci/hotplug/shpchp_hpc.c
++++ b/drivers/pci/hotplug/shpchp_hpc.c
+@@ -944,8 +944,8 @@ int shpc_init(struct controller *ctrl, s
+ ctrl->pci_dev = pdev; /* pci_dev of the P2P bridge */
+ ctrl_dbg(ctrl, "Hotplug Controller:\n");
+
+- if ((pdev->vendor == PCI_VENDOR_ID_AMD) || (pdev->device ==
+- PCI_DEVICE_ID_AMD_GOLAM_7450)) {
++ if (pdev->vendor == PCI_VENDOR_ID_AMD &&
++ pdev->device == PCI_DEVICE_ID_AMD_GOLAM_7450) {
+ /* amd shpc driver doesn't use Base Offset; assume 0 */
+ ctrl->mmio_base = pci_resource_start(pdev, 0);
+ ctrl->mmio_size = pci_resource_len(pdev, 0);
--- /dev/null
+ecryptfs-flush-file-in-vma-close.patch
+i2c-algo-bit-generate-correct-i2c-address-sequence-for-10-bit-target.patch
+ecryptfs-extend-array-bounds-for-all-filename-chars.patch
+crypto-mv_cesa-fix-hashing-of-chunks-1920-bytes.patch
+drm-integer-overflow-in-drm_mode_dirtyfb_ioctl.patch
+drm-radeon-kms-fix-up-gpio-i2c-mask-bits-for-r4xx-for-real.patch
+drm-i915-ivybridge-still-has-fences.patch
+drm-i915-turn-on-a-required-3d-clock-gating-bit-on-sandybridge.patch
+drm-i915-turn-on-another-required-clock-gating-bit-on-gen6.patch
+drm-ttm-request-zeroed-system-memory-pages-for-new-tt-buffer-objects.patch
+drm-i915-fix-cb-tuning-check-for-ilk.patch
+pci-hotplug-shpchp-don-t-blindly-claim-non-amd-0x7450-device-ids.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
