linux-stable.git/drivers/media, branch v3.12.35

[media] usbvision-video: two use after frees

2014-11-19T21:46:10+00:00

commit 470a9147899500eb4898f77816520c4b4aa1a698 upstream.

The lock has been freed in usbvision_release() so there is no need to
call mutex_unlock() here.

Signed-off-by: Dan Carpenter 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

media: tda7432: Fix setting TDA7432_MUTE bit for TDA7432_RF register

2014-11-13T18:02:26+00:00

commit 91ba0e59babdb3c7aca836a65f1095b3eaff7b06 upstream.

Fix a copy-paste bug when converting to the control framework.

Fixes: commit 5d478e0de871 ("[media] tda7432: convert to the control framework")

Signed-off-by: Axel Lin 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

media: ds3000: fix LNB supply voltage on Tevii S480 on initialization

2014-11-13T18:02:26+00:00

commit 8c5bcded11cb607b1bb5920de3b9c882136d27db upstream.

The Tevii S480 outputs 18V on startup for the LNB supply voltage and does not
automatically power down. This blocks other receivers connected
to a satellite channel router (EN50494), since the receivers can not send the
required DiSEqC sequences when the Tevii card is connected to a the same SCR.

This patch switches off the LNB supply voltage on initialization of the frontend.

[mchehab@osg.samsung.com: add a comment about why we're explicitly
 turning off voltage at device init]
Signed-off-by: Ulrich Eckhardt 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

media: em28xx-v4l: give back all active video buffers to the vb2 core properly on streaming stop

2014-11-13T18:02:25+00:00

commit 627530c32a43283474e9dd3e954519410ffa033a upstream.

When a new video frame is started, the driver takes the next video buffer from
the list of active buffers and moves it to dev->usb_ctl.vid_buf / dev->usb_ctl.vbi_buf
for further processing.

On streaming stop we currently only give back the pending buffers from the list
but not the ones which are currently processed.

This causes the following warning from the vb2 core since kernel 3.15:

...
 ------------[ cut here ]------------
 WARNING: CPU: 1 PID: 2284 at drivers/media/v4l2-core/videobuf2-core.c:2115 __vb2_queue_cancel+0xed/0x150 [videobuf2_core]()
 [...]
 Call Trace:
  [] dump_stack+0x48/0x69
  [] warn_slowpath_common+0x79/0x90
  [] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
  [] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
  [] warn_slowpath_null+0x1d/0x20
  [] __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
  [] vb2_internal_streamoff+0x35/0x90 [videobuf2_core]
  [] vb2_streamoff+0x35/0x60 [videobuf2_core]
  [] vb2_ioctl_streamoff+0x37/0x40 [videobuf2_core]
  [] v4l_streamoff+0x15/0x20 [videodev]
  [] __video_do_ioctl+0x23d/0x2d0 [videodev]
  [] ? video_ioctl2+0x20/0x20 [videodev]
  [] video_usercopy+0x203/0x5a0 [videodev]
  [] ? video_ioctl2+0x20/0x20 [videodev]
  [] ? fsnotify+0x1e7/0x2b0
  [] video_ioctl2+0x12/0x20 [videodev]
  [] ? video_ioctl2+0x20/0x20 [videodev]
  [] v4l2_ioctl+0xee/0x130 [videodev]
  [] ? v4l2_open+0xf0/0xf0 [videodev]
  [] do_vfs_ioctl+0x2e2/0x4d0
  [] ? vfs_write+0x13c/0x1c0
  [] ? vfs_writev+0x2f/0x50
  [] SyS_ioctl+0x58/0x80
  [] sysenter_do_call+0x12/0x12
 ---[ end trace 5545f934409f13f4 ]---
...

Many thanks to Hans Verkuil, whose recently added check in the vb2 core unveiled
this long standing issue and who has investigated it further.

Signed-off-by: Frank Schäfer 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

media: usb: uvc: add a quirk for Dell XPS M1330 webcam

2014-11-13T18:02:25+00:00

commit 62ea864f84fed6e04dd033d500d4c9183a83d590 upstream.

As reported on [1], this device needs this quirk to be able to
reliably initialise the webcam.

[1] http://ubuntuforums.org/showthread.php?t=2145996

Cc: stable@vger.kernel.org
Signed-off-by: Paul Fertser 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

media: v4l2-common: fix overflow in v4l_bound_align_image()

2014-11-13T18:02:24+00:00

commit 3bacc10cd4a85bc70bc0b6c001d3bf995c7fe04c upstream.

Fix clamp_align() used in v4l_bound_align_image() to prevent overflow
when passed large value like UINT32_MAX.

 In the current implementation:
    clamp_align(UINT32_MAX, 8, 8192, 3)

returns 8, because in line:

    x = (x + (1 << (align - 1))) & mask;

x overflows to (-1 + 4) & 0x7 = 3, while expected value is 8192.

v4l_bound_align_image() is heavily used in VIDIOC_S_FMT and
VIDIOC_SUBDEV_S_FMT ioctls handlers, and documentation of the latter
explicitly states that:

"The modified format should be as close as possible to the original
request."
  -- http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-fmt.html

Thus one would expect, that passing UINT32_MAX as format width and
height will result in setting maximum possible resolution for the
device. Particularly, when the driver doesn't support
VIDIOC_ENUM_FRAMESIZES ioctl, which is common in the codebase.

Fixes changeset: b0d3159be9a3

Signed-off-by: Maciej Matraszek 
Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

[media] ttusb-dec: buffer overflow in ioctl

2014-11-13T18:02:03+00:00

commit f2e323ec96077642d397bb1c355def536d489d16 upstream.

We need to add a limit check here so we don't overflow the buffer.

Signed-off-by: Dan Carpenter 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

media: vb2: fix VBI/poll regression

2014-10-13T14:09:20+00:00

commit 58d75f4b1ce26324b4d809b18f94819843a98731 upstream.

The recent conversion of saa7134 to vb2 unconvered a poll() bug that
broke the teletext applications alevt and mtt. These applications
expect that calling poll() without having called VIDIOC_STREAMON will
cause poll() to return POLLERR. That did not happen in vb2.

This patch fixes that behavior. It also fixes what should happen when
poll() is called when STREAMON is called but no buffers have been
queued. In that case poll() will also return POLLERR, but only for
capture queues since output queues will always return POLLOUT
anyway in that situation.

This brings the vb2 behavior in line with the old videobuf behavior.

Signed-off-by: Hans Verkuil 
Acked-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

media: adv7604: fix inverted condition

2014-10-13T13:41:37+00:00

commit 77639ff2b3404a913b8037d230a384798b854bae upstream.

The log_status function should show HDMI information, but the test checking for
an HDMI input was inverted. Fix this.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

media: cx18: fix kernel oops with tda8290 tuner

2014-10-13T13:41:37+00:00

commit 6a03dc92cc2edfa2257502557b9f714893987383 upstream.

This was caused by an uninitialized setup.config field.

Based on a suggestion from Devin Heitmueller.

Signed-off-by: Hans Verkuil 
Thanks-to: Devin Heitmueller 
Reported-by: Scott Robinson 
Tested-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby