linux-toradex.git/drivers, branch v3.1.2

xen-gntalloc: signedness bug in add_grefs()

2011-11-21T22:35:26+00:00

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:35:26+00:00

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:35:25+00:00

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

b43: refuse to load unsupported firmware

2011-11-21T22:35:24+00:00

[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

staging: brcm80211: fill in proper rx rate in mac80211 rx status

2011-11-21T22:35:24+00:00

commit 5a84d6ad4c9306afb467a600a4c6d7b50da49440 upstream.

The brcmsmac driver supports different rates on 5GHz but this is not
taken into account when providing the rate index in the receive
status information passed to mac80211.

Reviewed-by: Roland Vossen 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Henry Ptasinski 
Signed-off-by: Arend van Spriel 
Signed-off-by: Greg Kroah-Hartman

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

2011-11-21T22:35:23+00:00

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:35:20+00:00

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:35:20+00:00

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:35:19+00:00

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

virtio-pci: fix use after free

2011-11-21T22:35:17+00:00

commit 72103bd1285211440621f2c46f4fce377584de54 upstream.

Commit 31a3ddda166cda86d2b5111e09ba4bda5239fae6 introduced
a use after free in virtio-pci. The main issue is
that the release method signals removal of the virtio device,
while remove signals removal of the pci device.

For example, on driver removal or hot-unplug,
virtio_pci_release_dev is called before virtio_pci_remove.
We then might get a crash as virtio_pci_remove tries to use the
device freed by virtio_pci_release_dev.

We allocate/free all resources together with the
pci device, so we can leave the release method empty.

Signed-off-by: Michael S. Tsirkin 
Acked-by: Amit Shah 
Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman