linux/drivers, branch v3.0.10

xen-gntalloc: signedness bug in add_grefs()

2011-11-21T22:31:24Z

commit 99cb2ddcc617f43917e94a4147aa3ccdb2bcd77e upstream. gref->gref_id is unsigned so the error handling didn't work. gnttab_grant_foreign_access() returns an int type, so we can add a cast here, and it doesn't cause any problems. gnttab_grant_foreign_access() can return a variety of errors including -ENOSPC, -ENOSYS and -ENOMEM. Signed-off-by: Dan Carpenter Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

xen-gntalloc: integer overflow in gntalloc_ioctl_alloc()

2011-11-21T22:31:24Z

commit 21643e69a4c06f7ef155fbc70e3fba13fba4a756 upstream. On 32 bit systems a high value of op.count could lead to an integer overflow in the kzalloc() and gref_ids would be smaller than expected. If the you triggered another integer overflow in "if (gref_size + op.count > limit)" then you'd probably get memory corruption inside add_grefs(). Signed-off-by: Dan Carpenter Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

mfd: Fix twl4030 dependencies for audio codec

2011-11-21T22:31:23Z

commit f09ee0451a44a4e913a7c3cec3805508f7de6c54 upstream. The codec for Devkit8000 (TWL4030) was not detected except when build with CONFIG_SND_SOC_ALL_CODECS. twl-core.c still uses the CONFIG_TWL4030_CODEC for twl_has_codec(). In commit 57fe7251f5bfc4332f24479376de48a1e8ca6211 the CONFIG_TWL4030_CODEC was renamed into CONFIG_MFD_TWL4030_AUDIO, thatswhy the codec was not detected. This patch renames the CONFIG_ TWL4030_CODEC into CONFIG_MFD_TWL4030_AUDIO in twl-core.c. Signed-off-by: Thomas Weber Acked-by: Peter Ujfalusi Signed-off-by: Samuel Ortiz Cc: Jarkko Nikula Signed-off-by: Greg Kroah-Hartman

md/raid5: abort any pending parity operations when array fails.

2011-11-21T22:31:22Z

commit 9a3f530f39f4490eaa18b02719fb74ce5f4d2d86 upstream. When the number of failed devices exceeds the allowed number we must abort any active parity operations (checks or updates) as they are no longer meaningful, and can lead to a BUG_ON in handle_parity_checks6. This bug was introduce by commit 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8 in 2.6.29. Reported-by: Manish Katiyar Tested-by: Manish Katiyar Acked-by: Dan Williams Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

b43: refuse to load unsupported firmware

2011-11-21T22:31:22Z

[This patch is supposed to be applied in 3.1 (and maybe older) branches only.] New kernels support newer firmware that users may try to incorrectly use with older kernels. Display error and explain the problem in such a case Signed-off-by: Rafał Miłecki Signed-off-by: Greg Kroah-Hartman

drm/i915: enable ring freq scaling, RC6 and graphics turbo on Ivy Bridge v3

2011-11-21T22:31:20Z

commit 1c70c0cebd1295a42fec75045b8a6b4419cedef3 upstream. They use the same register interfaces, so we can simply enable the existing code on IVB. v2: - resolve conflict with ring freq scaling, we can enable it too v3: - resolve conflict again, this time on drm-intel-next Signed-off-by: Jesse Barnes Signed-off-by: Keith Packard Signed-off-by: Robert Hooker Acked-by: Leann Ogasawara Acked-by: Herton Krzesinski Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman

Revert "leds: save the delay values after a successful call to blink_set()"

2011-11-21T22:31:19Z

commit cb871513f656bdfc48b185b55f37857b5c750c40 upstream. Revert commit 6123b0e274503a0d3588e84fbe07c9aa01bfaf5d. The problem this patch intends to solve has alreadqy been fixed by commit 7a5caabd090b ("drivers/leds/ledtrig-timer.c: fix broken sysfs delay handling"). Signed-off-by: Johan Hovold Cc: Antonio Ospite Cc: Johannes Berg Cc: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: make an aux failure debug only

2011-11-21T22:31:16Z

commit 091264f0bc12419560ac64fcef4567809d611658 upstream. Can happen when there is no DP panel attached, confusing users. Make it debug only. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/nouveau: initialize chan->fence.lock before use

2011-11-21T22:31:16Z

commit 5e60ee780e792efe6dce97eceb110b1d30bab850 upstream. Fence lock needs to be initialized before any call to nouveau_channel_put because it calls nouveau_channel_idle->nouveau_fence_update which uses fence lock. BUG: spinlock bad magic on CPU#0, test/24134 lock: ffff88019f90dba8, .magic: 00000000, .owner: /-1, .owner_cpu: 0 Pid: 24134, comm: test Not tainted 3.0.0-nv+ #800 Call Trace: spin_bug+0x9c/0xa3 do_raw_spin_lock+0x29/0x13c _raw_spin_lock+0x1e/0x22 nouveau_fence_update+0x2d/0xf1 nouveau_channel_idle+0x22/0xa0 nouveau_channel_put_unlocked+0x84/0x1bd nouveau_channel_put+0x20/0x24 nouveau_channel_alloc+0x4ec/0x585 nouveau_ioctl_fifo_alloc+0x50/0x130 drm_ioctl+0x289/0x361 do_vfs_ioctl+0x4dd/0x52c sys_ioctl+0x42/0x65 system_call_fastpath+0x16/0x1b It's easily triggerable from userspace. Additionally remove double initialization of chan->fence.pending. Signed-off-by: Marcin Slusarz Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix object refcount leak on mmappable size limit error path.

2011-11-21T22:31:15Z

commit 14660ccd599dc7bd6ecef17408bd76dc853f9b77 upstream. I've been seeing memory leaks on my system in the form of large (300-400MB) GEM objects created by now-dead processes laying around clogging up memory. I usually notice when it gets to about 1.2GB of them. Hopefully this clears up the issue, but I just found this bug by inspection. Signed-off-by: Eric Anholt Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman