summaryrefslogtreecommitdiffstats
path: root/drivers/media/video/cx18/cx18-fileops.c
diff options
context:
space:
mode:
authorSimon Farnsworth <simon.farnsworth@onelan.co.uk>2011-09-05 12:23:12 -0300
committerMauro Carvalho Chehab <mchehab@redhat.com>2011-09-18 08:03:39 -0300
commit09fc9802c31a9358a4e34642aa5f569111752879 (patch)
treeb07a8c6e035df000702b3f2bbfaeb8acd85418d6 /drivers/media/video/cx18/cx18-fileops.c
parent16e3d2f4fab6e001a79705fa273418afc10188f8 (diff)
downloadlinux-stable-09fc9802c31a9358a4e34642aa5f569111752879.tar.gz
linux-stable-09fc9802c31a9358a4e34642aa5f569111752879.tar.bz2
linux-stable-09fc9802c31a9358a4e34642aa5f569111752879.zip
[media] cx18: Fix videobuf capture
When we moved to 3.0, we found that the cx18 driver was oopsing on close with: NULL pointer deref at: [ 2290.461009] Call Trace: [ 2290.461009] [<c046007b>] ? pm_qos_add_request+0xc/0x6e [ 2290.461009] [<c082631c>] __mutex_lock_common+0x87/0x125 [ 2290.461009] [<f8970e92>] ? cx18_queue_flush+0x31/0x87 [cx18] [ 2290.461009] [<c0436b85>] ? __might_sleep+0x29/0xe4 [ 2290.461009] [<c0826515>] __mutex_lock_slowpath+0x25/0x27 [ 2290.461009] [<c08264b2>] ? mutex_lock+0x2e/0x3b [ 2290.461009] [<c08264b2>] mutex_lock+0x2e/0x3b [ 2290.461009] [<f88d3137>] videobuf_queue_lock+0x13/0x15 [videobuf_core] [ 2290.461009] [<f88d3f86>] __videobuf_free+0xfc/0x112 [videobuf_core] [ 2290.461009] [<f89741e6>] cx18_v4l2_close+0x158/0x172 [cx18] [ 2290.461009] [<c0507522>] ? cpumask_next+0x1a/0x1d [ 2290.461009] [<f88a319d>] v4l2_release+0x35/0x52 [videodev] [ 2290.461009] [<c04f5717>] fput+0x100/0x1a5 [ 2290.461009] [<c04f2e09>] filp_close+0x5c/0x64 [ 2290.461009] [<c04f2e70>] sys_close+0x5f/0x93 [ 2290.461009] [<c082cd5f>] sysenter_do_call+0x12/0x28 Some digging showed that a merge at some previous point partially added broken mmap() support, causing this trace. Remove the broken code completely. On top of that, the calculation in place for "buffer full" depended on UYUV instead of HM12, while our GStreamer code was picking HM12 in some circumstances. Finally, the V4L2_CAP_STREAMING capability was never exposed. Patch it into the YUV encoder node only. Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'drivers/media/video/cx18/cx18-fileops.c')
-rw-r--r--drivers/media/video/cx18/cx18-fileops.c2
1 files changed, 0 insertions, 2 deletions
diff --git a/drivers/media/video/cx18/cx18-fileops.c b/drivers/media/video/cx18/cx18-fileops.c
index 07411f34885a..14cb961c22bd 100644
--- a/drivers/media/video/cx18/cx18-fileops.c
+++ b/drivers/media/video/cx18/cx18-fileops.c
@@ -784,8 +784,6 @@ int cx18_v4l2_close(struct file *filp)
cx18_release_stream(s);
} else {
cx18_stop_capture(id, 0);
- if (id->type == CX18_ENC_STREAM_TYPE_YUV)
- videobuf_mmap_free(&id->vbuf_q);
}
kfree(id);
mutex_unlock(&cx->serialize_lock);