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

media: smiapp: Only some selection targets are settable

2014-12-16T17:09:42+00:00

commit b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 upstream.

Setting a non-settable selection target caused BUG() to be called. The check
for valid selections only takes the selection target into account, but does
not tell whether it may be set, or only get. Fix the issue by simply
returning an error to the user.

Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: ttusb-dec: buffer overflow in ioctl

2014-11-21T17:22:54+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: Greg Kroah-Hartman

media: tda7432: Fix setting TDA7432_MUTE bit for TDA7432_RF register

2014-11-14T16:47:56+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: Greg Kroah-Hartman

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

2014-11-14T16:47:56+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: Greg Kroah-Hartman

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

2014-11-14T16:47:56+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: Greg Kroah-Hartman

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

2014-11-14T16:47:56+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: Greg Kroah-Hartman

media: vb2: fix VBI/poll regression

2014-10-09T19:18:42+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: Greg Kroah-Hartman

media: cx18: fix kernel oops with tda8290 tuner

2014-10-05T21:54:14+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: Greg Kroah-Hartman

media: media-device: Remove duplicated memset() in media_enum_entities()

2014-09-17T16:03:57+00:00

commit f8ca6ac00d2ba24c5557f08f81439cd3432f0802 upstream.

After the zeroing the whole struct struct media_entity_desc u_ent,
it is no longer necessary to memset(0) its u_ent.name field.

Signed-off-by: Salva Peiró 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: au0828: Only alt setting logic when needed

2014-09-17T16:03:57+00:00

commit 64ea37bbd8a5815522706f0099ad3f11c7537e15 upstream.

It seems that there's a bug at au0828 hardware/firmware
related to alternate setting: when the device is already at
alt 5, a further call causes the URBs to receive -ESHUTDOWN.

I found two different encarnations of this issue:

1) at qv4l2, it fails the second time we try to open the
video screen;
2) at xawtv, when audio underrun occurs, with is very
frequent, at least on my test machine.

The fix is simple: just check if alt=5 before calling
set_usb_interface().

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman