linux-toradex.git/drivers/media/v4l2-core, branch v3.14.24

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

2014-11-14T16:59:53+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:21:27+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: media: v4l2-core: v4l2-dv-timings.c: Cleaning up code wrong value used in aspect ratio

2014-07-31T19:52:53+00:00

commit f71920efb1066d71d74811e1dbed658173adf9bf upstream.

Wrong value used in same cases for the aspect ratio.

Signed-off-by: Rickard Strandqvist 
Acked-by: Lad, Prabhakar 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode

2014-06-07T17:28:29+00:00

commit 97d9d23dda6f37d90aefeec4ed619d52df525382 upstream.

If a struct contains 64-bit fields, it is aligned on 64-bit boundaries
within containing structs in 64-bit compilations. This is the case with
struct v4l2_window, which contains pointers and is embedded into struct
v4l2_format, and that one is embedded into struct v4l2_create_buffers.
Unlike some other structs, used as a part of the kernel ABI as ioctl()
arguments, that are packed, these structs aren't packed. This isn't a
problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains
a bug, that triggers in such 64-bit builds. That code wrongly assumes,
that in struct v4l2_create_buffers, struct v4l2_format immediately follows
the __u32 memory field, which in fact isn't the case. This bug wasn't
visible until now, because until recently hardly any applications used
this ioctl() and mostly embedded 32-bit only drivers implemented it. This
is changing now with addition of this ioctl() to some USB drivers, e.g.
UVC. This patch fixes the bug by copying parts of struct
v4l2_create_buffers separately.

Signed-off-by: Guennadi Liakhovetski 
Acked-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: v4l2-compat-ioctl32: fix wrong VIDIOC_SUBDEV_G/S_EDID32 support

2014-05-06T14:59:31+00:00

commit bc826d6e39fe5f09cbadf8723e9183e6331b586f upstream.

The wrong ioctl numbers were used due to a copy-and-paste error.

Signed-off-by: Hans Verkuil 
Acked-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: v4l2-dv-timings: add module name, description, license

2014-05-06T14:59:31+00:00

commit c4885ada88e4331f8ac56d14296d0058359db2d7 upstream.

I completely forgot to add them when I made this module. Loading this module
without it will taint the kernel, which is not intended.

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

[media] v4l2-dv-timings: fix GTF calculation

2014-02-04T08:45:47+00:00

Round off image width to nearest 8 (GTF_CELL_GRAN)

A source sending a GTF (Generalized Timing Formula) format have no means of
signalling image width. The assumed aspect ratio may result in an odd image
width but according to the standard image width should be in multiple of 8.

Cc: Mats Randgaard 
Signed-off-by: Martin Bugge 
Reviewed-by: Hans Verkuil 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

[media] vb2: Check if there are buffers before streamon

2014-02-04T08:30:21+00:00

This patch adds a test preventing streamon() if there is no buffer
ready.

Without this patch, a user could call streamon() before
preparing any buffer. This leads to a situation where if he calls
close() before calling streamoff() the device is kept streaming.

Signed-off-by: Ricardo Ribalda Delgado 
Reviewed-by: Marek Szyprowski 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

[media] Revert "[media] videobuf_vm_{open,close} race fixes"

2014-02-04T08:29:46+00:00

This reverts commit a242f426108c284049a69710f871cc9f11b13e61.

That commit actually caused deadlocks, rather then fixing them.

If ext_lock is set to NULL (otherwise videobuf_queue_lock doesn't do
anything), then you get this deadlock:

The driver's mmap function calls videobuf_mmap_mapper which calls
videobuf_queue_lock on q. videobuf_mmap_mapper calls  __videobuf_mmap_mapper,
__videobuf_mmap_mapper calls videobuf_vm_open and videobuf_vm_open
calls videobuf_queue_lock on q (introduced by above patch): deadlocked.

This affects drivers using dma-contig and dma-vmalloc. Only dma-sg is
not affected since it doesn't call videobuf_vm_open from __videobuf_mmap_mapper.

Most drivers these days have a non-NULL ext_lock. Those that still use
NULL there are all fairly obscure drivers, which is why this hasn't been
seen earlier.

Since everything worked perfectly fine for many years I prefer to just
revert this patch rather than trying to fix it. videobuf is quite fragile
and I rather not touch it too much. Work is (slowly) progressing to move
everything over to vb2 or at the very least use non-NULL ext_lock in
videobuf.

Signed-off-by: Hans Verkuil 
Cc:       # for v3.11 and up
Cc: Al Viro 
Reported-by: Pete Eberlein 
Signed-off-by: Mauro Carvalho Chehab

[media] media: v4l2-dev: fix video device index assignment

2014-01-27T23:42:42+00:00

The side effect of commit 1056e4388b045 ("v4l2-dev: Fix race condition on
__video_register_device") is the increased number of index value assigned
on video_device registration. Before that commit video_devices were
numbered from 0, after it, the indexes starts from 1, because get_index()
always count the device, which is being registered. Some device drivers
rely on video_device index number for internal purposes, i.e. s5p-mfc
driver stopped working after that patch. This patch restores the old method
of numbering the video_device indexes.

Cc: stable@vger.kernel.org # for v3.12
Signed-off-by: Marek Szyprowski 
Acked-by: Sakari Ailus 
Acked-by: Ricardo Ribalda 
Signed-off-by: Mauro Carvalho Chehab