From: Greg Kroah-Hartman Date: Sun, 27 Nov 2011 03:28:45 +0000 (-0800) Subject: 3.0 patches X-Git-Tag: v3.0.13~24 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=652b83cb1657eaac7c721cc820d8e015f331f4e4;p=thirdparty%2Fkernel%2Fstable-queue.git 3.0 patches added patches: crypto-mv_cesa-fix-hashing-of-chunks-1920-bytes.patch drm-i915-fix-cb-tuning-check-for-ilk.patch drm-i915-ivybridge-still-has-fences.patch drm-i915-turn-on-another-required-clock-gating-bit-on-gen6.patch drm-i915-turn-on-a-required-3d-clock-gating-bit-on-sandybridge.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-ttm-request-zeroed-system-memory-pages-for-new-tt-buffer-objects.patch ecryptfs-extend-array-bounds-for-all-filename-chars.patch ecryptfs-flush-file-in-vma-close.patch i2c-algo-bit-generate-correct-i2c-address-sequence-for-10-bit-target.patch pci-hotplug-shpchp-don-t-blindly-claim-non-amd-0x7450-device-ids.patch --- diff --git a/queue-3.0/crypto-mv_cesa-fix-hashing-of-chunks-1920-bytes.patch b/queue-3.0/crypto-mv_cesa-fix-hashing-of-chunks-1920-bytes.patch new file mode 100644 index 00000000000..8142c5338d5 --- /dev/null +++ b/queue-3.0/crypto-mv_cesa-fix-hashing-of-chunks-1920-bytes.patch @@ -0,0 +1,43 @@ +From 274252862f386b7868f35bf5ceaa5391a8ccfdf3 Mon Sep 17 00:00:00 2001 +From: Phil Sutter +Date: Wed, 16 Nov 2011 18:28:01 +0100 +Subject: crypto: mv_cesa - fix hashing of chunks > 1920 bytes + +From: Phil Sutter + +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 +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + 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)); diff --git a/queue-3.0/drm-i915-fix-cb-tuning-check-for-ilk.patch b/queue-3.0/drm-i915-fix-cb-tuning-check-for-ilk.patch new file mode 100644 index 00000000000..2f84ea340de --- /dev/null +++ b/queue-3.0/drm-i915-fix-cb-tuning-check-for-ilk.patch @@ -0,0 +1,36 @@ +From cb0e093162d7b6589c2217a00e2abfef686b32d6 Mon Sep 17 00:00:00 2001 +From: Jesse Barnes +Date: Thu, 28 Jul 2011 14:50:30 -0700 +Subject: drm/i915: fix CB tuning check for ILK+ + +From: Jesse Barnes + +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 +Signed-off-by: Keith Packard +Signed-off-by: Timo Aaltonen +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.0/drm-i915-ivybridge-still-has-fences.patch b/queue-3.0/drm-i915-ivybridge-still-has-fences.patch new file mode 100644 index 00000000000..d4b8f953cc7 --- /dev/null +++ b/queue-3.0/drm-i915-ivybridge-still-has-fences.patch @@ -0,0 +1,50 @@ +From 775d17b6ca4357048f36c22151335addfe15db4b Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Sun, 9 Oct 2011 21:52:01 +0200 +Subject: drm/i915: Ivybridge still has fences! + +From: Daniel Vetter + +commit 775d17b6ca4357048f36c22151335addfe15db4b upstream. + +So don't forget to restore them on resume and dump them into +the error state. + +Signed-off-by: Daniel Vetter +Reviewed-by: Chris Wilson +Signed-off-by: Keith Packard +Signed-off-by: Greg Kroah-Hartman + +--- + 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]); diff --git a/queue-3.0/drm-i915-turn-on-a-required-3d-clock-gating-bit-on-sandybridge.patch b/queue-3.0/drm-i915-turn-on-a-required-3d-clock-gating-bit-on-sandybridge.patch new file mode 100644 index 00000000000..0f6fc42c028 --- /dev/null +++ b/queue-3.0/drm-i915-turn-on-a-required-3d-clock-gating-bit-on-sandybridge.patch @@ -0,0 +1,51 @@ +From 406478dc911e16677fbd9c84d1d50cdffbc031ab Mon Sep 17 00:00:00 2001 +From: Eric Anholt +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 + +commit 406478dc911e16677fbd9c84d1d50cdffbc031ab upstream. + +Fixes rendering failures in Unigine Tropics and Sanctuary and the mesa +"fire" demo. + +Signed-off-by: Eric Anholt +Signed-off-by: Keith Packard +Signed-off-by: Greg Kroah-Hartman + +--- + 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: diff --git a/queue-3.0/drm-i915-turn-on-another-required-clock-gating-bit-on-gen6.patch b/queue-3.0/drm-i915-turn-on-another-required-clock-gating-bit-on-gen6.patch new file mode 100644 index 00000000000..9410178a071 --- /dev/null +++ b/queue-3.0/drm-i915-turn-on-another-required-clock-gating-bit-on-gen6.patch @@ -0,0 +1,49 @@ +From 9ca1d10d748e56964de95e3ed80211b192f56cf4 Mon Sep 17 00:00:00 2001 +From: Eric Anholt +Date: Mon, 7 Nov 2011 16:07:05 -0800 +Subject: drm/i915: Turn on another required clock gating bit on gen6. + +From: Eric Anholt + +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 +Signed-off-by: Keith Packard +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.0/drm-integer-overflow-in-drm_mode_dirtyfb_ioctl.patch b/queue-3.0/drm-integer-overflow-in-drm_mode_dirtyfb_ioctl.patch new file mode 100644 index 00000000000..9e16e4028d0 --- /dev/null +++ b/queue-3.0/drm-integer-overflow-in-drm_mode_dirtyfb_ioctl.patch @@ -0,0 +1,48 @@ +From a5cd335165e31db9dbab636fd29895d41da55dd2 Mon Sep 17 00:00:00 2001 +From: Xi Wang +Date: Wed, 23 Nov 2011 01:12:01 -0500 +Subject: drm: integer overflow in drm_mode_dirtyfb_ioctl() + +From: Xi Wang + +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 +Signed-off-by: Xi Wang +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + 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. + * diff --git a/queue-3.0/drm-radeon-kms-fix-up-gpio-i2c-mask-bits-for-r4xx-for-real.patch b/queue-3.0/drm-radeon-kms-fix-up-gpio-i2c-mask-bits-for-r4xx-for-real.patch new file mode 100644 index 00000000000..4303e38566a --- /dev/null +++ b/queue-3.0/drm-radeon-kms-fix-up-gpio-i2c-mask-bits-for-r4xx-for-real.patch @@ -0,0 +1,46 @@ +From d724502a9d7a46f4a56a1663b1f50d2dc9d1ef40 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +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 + +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 +Cc: Jean Delvare +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + 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) && diff --git a/queue-3.0/drm-ttm-request-zeroed-system-memory-pages-for-new-tt-buffer-objects.patch b/queue-3.0/drm-ttm-request-zeroed-system-memory-pages-for-new-tt-buffer-objects.patch new file mode 100644 index 00000000000..390360c821f --- /dev/null +++ b/queue-3.0/drm-ttm-request-zeroed-system-memory-pages-for-new-tt-buffer-objects.patch @@ -0,0 +1,34 @@ +From ff02b13f6867af72682d7a9bb9bd705f9af2bab0 Mon Sep 17 00:00:00 2001 +From: Ben Skeggs +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 + +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 +Signed-off-by: Ben Skeggs +Tested-by: Marcin Slusarz +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-3.0/ecryptfs-extend-array-bounds-for-all-filename-chars.patch b/queue-3.0/ecryptfs-extend-array-bounds-for-all-filename-chars.patch new file mode 100644 index 00000000000..422ef305c4e --- /dev/null +++ b/queue-3.0/ecryptfs-extend-array-bounds-for-all-filename-chars.patch @@ -0,0 +1,56 @@ +From 0f751e641a71157aa584c2a2e22fda52b52b8a56 Mon Sep 17 00:00:00 2001 +From: Tyler Hicks +Date: Wed, 23 Nov 2011 11:31:24 -0600 +Subject: eCryptfs: Extend array bounds for all filename chars + +From: Tyler Hicks + +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 +Reported-by: Michael Halcrow +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ + }; + + /** diff --git a/queue-3.0/ecryptfs-flush-file-in-vma-close.patch b/queue-3.0/ecryptfs-flush-file-in-vma-close.patch new file mode 100644 index 00000000000..75243b817a7 --- /dev/null +++ b/queue-3.0/ecryptfs-flush-file-in-vma-close.patch @@ -0,0 +1,62 @@ +From 32001d6fe9ac6b0423e674a3093aa56740849f3b Mon Sep 17 00:00:00 2001 +From: Tyler Hicks +Date: Mon, 21 Nov 2011 17:31:29 -0600 +Subject: eCryptfs: Flush file in vma close + +From: Tyler Hicks + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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, diff --git a/queue-3.0/i2c-algo-bit-generate-correct-i2c-address-sequence-for-10-bit-target.patch b/queue-3.0/i2c-algo-bit-generate-correct-i2c-address-sequence-for-10-bit-target.patch new file mode 100644 index 00000000000..e07db3a0f24 --- /dev/null +++ b/queue-3.0/i2c-algo-bit-generate-correct-i2c-address-sequence-for-10-bit-target.patch @@ -0,0 +1,41 @@ +From cc6bcf7d2ec2234e7b41770185e4dc826390185e Mon Sep 17 00:00:00 2001 +From: "Jeffrey (Sheng-Hui) Chu" +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" + +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 +Signed-off-by: Jean Delvare +Signed-off-by: Greg Kroah-Hartman + +--- + 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"); diff --git a/queue-3.0/pci-hotplug-shpchp-don-t-blindly-claim-non-amd-0x7450-device-ids.patch b/queue-3.0/pci-hotplug-shpchp-don-t-blindly-claim-non-amd-0x7450-device-ids.patch new file mode 100644 index 00000000000..eeda7c5a237 --- /dev/null +++ b/queue-3.0/pci-hotplug-shpchp-don-t-blindly-claim-non-amd-0x7450-device-ids.patch @@ -0,0 +1,54 @@ +From 4cac2eb158c6da0c761689345c6cc5df788a6292 Mon Sep 17 00:00:00 2001 +From: Bjorn Helgaas +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 + +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 +Cc: Joerg Roedel +Signed-off-by: Bjorn Helgaas +Signed-off-by: Jesse Barnes +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.0/series b/queue-3.0/series new file mode 100644 index 00000000000..7eaf387ac9d --- /dev/null +++ b/queue-3.0/series @@ -0,0 +1,12 @@ +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