upstream: [media] vb2: fix handling of data_offset and v4l2_plane.reserved[]
authorHans Verkuil <hans.verkuil@cisco.com>
Mon, 7 Apr 2014 11:44:56 +0000 (08:44 -0300)
committerChanho Park <chanho61.park@samsung.com>
Tue, 18 Nov 2014 02:56:09 +0000 (11:56 +0900)
commite23af393138545e0f755a65586a82fd76e03a071
treece7950c0a265415a8169ccb86a1f45feb08df044
parentf2387945d718d651b204fde55ba7cd2c154a6fa7
upstream: [media] vb2: fix handling of data_offset and v4l2_plane.reserved[]

The videobuf2-core did not zero the 'planes' array in __qbuf_userptr()
and __qbuf_dmabuf(). That's now memset to 0. Without this the reserved
array in struct v4l2_plane would be non-zero, causing v4l2-compliance
errors.

More serious is the fact that data_offset was not handled correctly:

- for capture devices it was never zeroed, which meant that it was
  uninitialized. Unless the driver sets it it was a completely random
  number. With the memset above this is now fixed.

- __qbuf_dmabuf had a completely incorrect length check that included
  data_offset.

- in __fill_vb2_buffer in the DMABUF case the data_offset field was
  unconditionally copied from v4l2_buffer to v4l2_plane when this
  should only happen in the output case.

- in the single-planar case data_offset was never correctly set to 0.
  The single-planar API doesn't support data_offset, so setting it
  to 0 is the right thing to do. This too is now solved by the memset.

All these issues were found with v4l2-compliance.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
drivers/media/v4l2-core/videobuf2-core.c