cron job: media_tree daily build: OK

2016-04-06 Thread Hans Verkuil 
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Thu Apr  7 04:00:17 CEST 2016
git branch: test
git hash:   bc5ccdbc990debbcae4602214dddc8d5fd38b01d
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3353-gcae47da
host hardware:  x86_64
host os:4.4.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Security Fix for CVE-2015-7833

2016-04-06 Thread Yuki Machida 
Hi Sasha,

On 2016年04月06日 11:43, Yuki Machida wrote:
> Hi Sasha,
> 
> I conformed that these patches for CVE-2015-7833 not applied at v4.1.20.
> 588afcc1c0e45358159090d95bf7b246fb67565
> fa52bd506f274b7619955917abfde355e3d19ff
I conformed that these patches not applied at v4.1.21.

> Could you please apply this CVE-2015-7833 fix for 4.1-stable ?
> 
> References:
> https://security-tracker.debian.org/tracker/CVE-2015-7833
> http://git.linuxtv.org/cgit.cgi/media_tree.git/commit?id=588afcc1c0e45358159090d95bf7b246fb67565
> http://git.linuxtv.org/cgit.cgi/media_tree.git/commit?id=fa52bd506f274b7619955917abfde355e3d19ff

These patches are already included since v4.5-rc1 in mainline.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=588afcc1c0e45358159090d95bf7b246fb67565f
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fa52bd506f274b7619955917abfde355e3d19ffe

> 
> Regards,
> Yuki Machida
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] [media] tpg: Export the tpg code from vivid as a module

2016-04-06 Thread Helen Koike 

Hi

On 01/04/2016 15:22, Mauro Carvalho Chehab wrote:

Hi Helen,

This is just a quick look on it. See below.

Em Fri, 1 Apr 2016 14:18:13 -0300
Helen Mae Koike Fornazier  escreveu:


The test pattern generator will be used by other drivers as the virtual
media controller (vimc)

Signed-off-by: Helen Mae Koike Fornazier 
---

The patch is based on 'media/master' branch and available at
 https://github.com/helen-fornazier/opw-staging tpg/review/vivid

Changes since last version:
* module name: tpg -> video-tpg
* header ifdef/define:
_TPG_H_ -> _MEDIA_TPG_H_
_TPG_COLORS_H_ -> _MEDIA_TPG_COLORS_H_

  drivers/media/platform/Kconfig  |2 +
  drivers/media/platform/Makefile |2 +
  drivers/media/platform/tpg/Kconfig  |5 +
  drivers/media/platform/tpg/Makefile |3 +
  drivers/media/platform/tpg/tpg-colors.c | 1415 ++
  drivers/media/platform/tpg/tpg-core.c   | 2334 +++
  drivers/media/platform/vivid/Kconfig|1 +
  drivers/media/platform/vivid/Makefile   |2 +-
  drivers/media/platform/vivid/vivid-core.h   |2 +-
  drivers/media/platform/vivid/vivid-tpg-colors.c | 1416 --
  drivers/media/platform/vivid/vivid-tpg-colors.h |   68 -
  drivers/media/platform/vivid/vivid-tpg.c| 2314 --
  drivers/media/platform/vivid/vivid-tpg.h|  598 --
  include/media/tpg-colors.h  |   68 +
  include/media/tpg.h |  597 ++
  15 files changed, 4429 insertions(+), 4398 deletions(-)
  create mode 100644 drivers/media/platform/tpg/Kconfig
  create mode 100644 drivers/media/platform/tpg/Makefile
  create mode 100644 drivers/media/platform/tpg/tpg-colors.c
  create mode 100644 drivers/media/platform/tpg/tpg-core.c
  delete mode 100644 drivers/media/platform/vivid/vivid-tpg-colors.c
  delete mode 100644 drivers/media/platform/vivid/vivid-tpg-colors.h
  delete mode 100644 drivers/media/platform/vivid/vivid-tpg.c
  delete mode 100644 drivers/media/platform/vivid/vivid-tpg.h
  create mode 100644 include/media/tpg-colors.h
  create mode 100644 include/media/tpg.h


Please, generate the patch with -M, for us to see what was changed,
instead of seeing a big diff where (I suspect that) 99% of the code
didn't change.

That helps a lot for us to know what actually changed, without needing
to compare everything line per line.


diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 201f5c2..8f7cf86 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -284,6 +284,8 @@ menuconfig V4L_TEST_DRIVERS
  
  if V4L_TEST_DRIVERS
  
+source "drivers/media/platform/tpg/Kconfig"

+
  source "drivers/media/platform/vivid/Kconfig"
  
  config VIDEO_VIM2M

diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index bbb7bd1..569dd1a 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -12,6 +12,8 @@ obj-$(CONFIG_VIDEO_OMAP3) += omap3isp/
  
  obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
  
+obj-$(CONFIG_VIDEO_TPG)			+= tpg/

+obj-$(CONFIG_VIDEO_VIMC)   += vimc/
  obj-$(CONFIG_VIDEO_VIVID) += vivid/
  obj-$(CONFIG_VIDEO_VIM2M) += vim2m.o
  
diff --git a/drivers/media/platform/tpg/Kconfig b/drivers/media/platform/tpg/Kconfig

new file mode 100644
index 000..1b6b19c0
--- /dev/null
+++ b/drivers/media/platform/tpg/Kconfig
@@ -0,0 +1,5 @@
+config VIDEO_TPG
+   tristate "Test Pattern Generator (TPG)"
+   default n
+   ---help---
+ Export functions to generate image patterns used in vivid and vimc 
drivers


No need to have a menu for this. The best would be to do define it as:

config VIDEO_TPG
tristate
depends on VIDEO_VIVID || VIDEO_VIMC

This way, it will be automatically selected if the driver(s) that
needs it is selected, without forcing the user to manually guess the
reverse dependency. It also makes life easier for distros that have
VIDEO_VIVID already enabled.

Regards,
Mauro
Conceptually, the tpg doesn't depends on vivid or vimc, it is a separate 
modules that export symbols conveniently used by Vivid, any other 
modules could use the tpg if they want to. Shouldn't we just let the 
"select VIDEO_V4L2_TPG" in the vivid's Kconfig? The tpg would be 
selected automatically.


Regards,
Helen



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT FIXES FOR v4.7] Fix videobuf2 plane validation

2016-04-06 Thread Sakari Ailus 
Hi Mauro,

(Resending the pull request, now rebased on fixes branch. It'd be nice to
have this in v4.6...)

This pull request contains two patches to fix the videobuf2 plane validation
issue introduced in v4.4 kernel. I've added cc stable to both of the
patches.

Please prioritise. Thanks!


The following changes since commit 405ddbfa68177b6169d09bc2308a39196a8eb64a:

  [media] Revert "[media] media: au0828 change to use Managed Media Controller 
API" (2016-03-31 15:09:04 -0300)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git vb2-overwrite-fix-error-on-fixes

for you to fetch changes up to 2559c388cc87869b52f95f7d11ca4c7130a56c41:

  videobuf2-v4l2: Verify planes array in buffer dequeueing (2016-04-07 00:34:14 
+0300)


Sakari Ailus (2):
  videobuf2-core: Check user space planes array in dqbuf
  videobuf2-v4l2: Verify planes array in buffer dequeueing

 drivers/media/v4l2-core/videobuf2-core.c | 10 +-
 drivers/media/v4l2-core/videobuf2-v4l2.c |  6 ++
 include/media/videobuf2-core.h   |  4 
 3 files changed, 15 insertions(+), 5 deletions(-)

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.7] Fix videobuf2 plane validation

2016-04-06 Thread Sakari Ailus 
Hi Mauro,

This pull request contains two patches to fix the videobuf2 plane validation
issue introduced in v4.4 kernel. I've added cc stable to both of the
patches.

Please prioritise. Thanks!


The following changes since commit d3f5193019443ef8e556b64f3cd359773c4d377b:

  Merge tag 'v4.6-rc1' into patchwork (2016-03-29 17:17:26 -0300)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git vb2-overwrite-fix-error

for you to fetch changes up to 05e337849107c2ae5484e2600acb0a86bcaf56fb:

  videobuf2-v4l2: Verify planes array in buffer dequeueing (2016-04-07 00:00:45 
+0300)


Sakari Ailus (2):
  videobuf2-core: Check user space planes array in dqbuf
  videobuf2-v4l2: Verify planes array in buffer dequeueing

 drivers/media/v4l2-core/videobuf2-core.c | 10 +-
 drivers/media/v4l2-core/videobuf2-v4l2.c |  6 ++
 include/media/videobuf2-core.h   |  4 
 3 files changed, 15 insertions(+), 5 deletions(-)

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] [media] media: Improve documentation for link_setup/link_modify

2016-04-06 Thread Sakari Ailus 
Hi Mauro,

On Wed, Apr 06, 2016 at 06:55:25AM -0700, Mauro Carvalho Chehab wrote:
> Those callbacks are called with the media_device.graph_mutex hold.
> 
> Add a note about that, as the code called by those notifiers should
> not be touching in the mutex.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> Acked-by: Sakari Ailus 
> ---
>  include/media/media-device.h | 3 ++-
>  include/media/media-entity.h | 3 +++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index b21ef244ad3e..44563ec17d45 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -311,7 +311,8 @@ struct media_entity_notify {
>   * @enable_source: Enable Source Handler function pointer
>   * @disable_source: Disable Source Handler function pointer
>   *
> - * @link_notify: Link state change notification callback
> + * @link_notify: Link state change notification callback. This callback is
> + * Called with the graph_mutex hold.

s/Called/called/
s/hold/held/

The indentation could be better, too.

>   *
>   * This structure represents an abstract high-level media device. It allows 
> easy
>   * access to entities and provides basic media device-level support. The
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index 6dc9e4e8cbd4..0b16ebe36db7 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -179,6 +179,9 @@ struct media_pad {
>   * @link_validate:   Return whether a link is valid from the entity point of
>   *   view. The media_entity_pipeline_start() function
>   *   validates all links by calling this operation. Optional.
> + *
> + * Note: Those ioctls should not touch the struct media_device.@graph_mutex
> + * field, as they're called with it already hold.

How about simply:

"these callbacks are called with struct media_device.@graph_mutex mutex
held"

?

They're not IOCTLs, and the above is more simple, too.

>   */
>  struct media_entity_operations {
>   int (*link_setup)(struct media_entity *entity,

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] [media] vimc: Virtual Media Controller core, capture and sensor

2016-04-06 Thread Helen Mae Koike Fornazier 
From: Helen Fornazier 

First version of the Virtual Media Controller.
Add a simple version of the core of the driver, the capture and
sensor nodes in the topology, generating a grey image in a hardcoded
format.

Signed-off-by: Helen Fornazier 
---

Changes since v2: update with current media master tree
- Add struct media_pipeline in vimc_cap_device
- Use vb2_v4l2_buffer instead of vb2_buffer
- Typos
- Remove usage of entity->type and use entity->function instead
- Remove fmt argument from queue setup
- Use ktime_get_ns instead of v4l2_get_timestamp
- Iterate over link's list using list_for_each_entry
- Use media_device_{init, cleanup}
- Use entity->use_count to keep track of entities instead of the old
entity->id
- Replace media_entity_init by media_entity_pads_init

 drivers/media/platform/Kconfig |   2 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/vimc/Kconfig|   6 +
 drivers/media/platform/vimc/Makefile   |   3 +
 drivers/media/platform/vimc/vimc-capture.c | 534 ++
 drivers/media/platform/vimc/vimc-capture.h |  28 ++
 drivers/media/platform/vimc/vimc-core.c| 595 +
 drivers/media/platform/vimc/vimc-core.h|  55 +++
 drivers/media/platform/vimc/vimc-sensor.c  | 277 ++
 drivers/media/platform/vimc/vimc-sensor.h  |  28 ++
 10 files changed, 1529 insertions(+)
 create mode 100644 drivers/media/platform/vimc/Kconfig
 create mode 100644 drivers/media/platform/vimc/Makefile
 create mode 100644 drivers/media/platform/vimc/vimc-capture.c
 create mode 100644 drivers/media/platform/vimc/vimc-capture.h
 create mode 100644 drivers/media/platform/vimc/vimc-core.c
 create mode 100644 drivers/media/platform/vimc/vimc-core.h
 create mode 100644 drivers/media/platform/vimc/vimc-sensor.c
 create mode 100644 drivers/media/platform/vimc/vimc-sensor.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 201f5c2..14ed03f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -284,6 +284,8 @@ menuconfig V4L_TEST_DRIVERS
 
 if V4L_TEST_DRIVERS
 
+source "drivers/media/platform/vimc/Kconfig"
+
 source "drivers/media/platform/vivid/Kconfig"
 
 config VIDEO_VIM2M
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index bbb7bd1..e4508fe 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_VIDEO_OMAP3) += omap3isp/
 
 obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
 
+obj-$(CONFIG_VIDEO_VIMC)   += vimc/
 obj-$(CONFIG_VIDEO_VIVID)  += vivid/
 obj-$(CONFIG_VIDEO_VIM2M)  += vim2m.o
 
diff --git a/drivers/media/platform/vimc/Kconfig 
b/drivers/media/platform/vimc/Kconfig
new file mode 100644
index 000..81279f4
--- /dev/null
+++ b/drivers/media/platform/vimc/Kconfig
@@ -0,0 +1,6 @@
+config VIDEO_VIMC
+   tristate "Virtual Media Controller Driver (VIMC)"
+   select VIDEO_V4L2_SUBDEV_API
+   default n
+   ---help---
+ Skeleton driver for Virtual Media Controller
diff --git a/drivers/media/platform/vimc/Makefile 
b/drivers/media/platform/vimc/Makefile
new file mode 100644
index 000..c45195e
--- /dev/null
+++ b/drivers/media/platform/vimc/Makefile
@@ -0,0 +1,3 @@
+vimc-objs := vimc-core.o vimc-capture.o vimc-sensor.o
+
+obj-$(CONFIG_VIDEO_VIMC) += vimc.o
diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
new file mode 100644
index 000..3fb8bfe
--- /dev/null
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -0,0 +1,534 @@
+/*
+ * vimc-capture.c Virtual Media Controller Driver
+ *
+ * Copyright (C) 2015 Helen Fornazier 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include "vimc-capture.h"
+
+struct vimc_cap_device {
+   struct vimc_ent_device ved;
+   struct video_device vdev;
+   struct v4l2_device *v4l2_dev;
+   struct device *dev;
+   struct v4l2_pix_format format;
+   struct vb2_queue queue;
+   struct list_head buf_list;
+   /* NOTE: in a real driver, a spin lock must be used to access the
+* queue because the frames are generated from a hardware interruption
+* and the isr is not allowed to sleep.
+* Even if it is not necessary a spinlock in the vimc driver, we
+* use it here as a code reference */
+

Re: [PATCH 1/2] v4l2-rect.h: new header with struct v4l2_rect helper functions.

2016-04-06 Thread Hans Verkuil 



On 04/06/2016 05:00 AM, Sakari Ailus wrote:

Hi Mauro,

On Sun, Apr 03, 2016 at 12:42:42PM -0700, Hans Verkuil wrote:

From: Hans Verkuil 

This makes it easier to share this code with any driver that needs to
manipulate the v4l2_rect datastructure.

Signed-off-by: Hans Verkuil 
---
  Documentation/DocBook/device-drivers.tmpl |   1 +
  include/media/v4l2-rect.h | 175 ++
  2 files changed, 176 insertions(+)
  create mode 100644 include/media/v4l2-rect.h

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index 184f3c7..893b2ca 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -233,6 +233,7 @@ X!Isound/sound_firmware.c
  !Iinclude/media/v4l2-mediabus.h
  !Iinclude/media/v4l2-mem2mem.h
  !Iinclude/media/v4l2-of.h
+!Iinclude/media/v4l2-rect.h
  !Iinclude/media/v4l2-subdev.h
  !Iinclude/media/videobuf2-core.h
  !Iinclude/media/videobuf2-v4l2.h
diff --git a/include/media/v4l2-rect.h b/include/media/v4l2-rect.h
new file mode 100644
index 000..c138557
--- /dev/null
+++ b/include/media/v4l2-rect.h
@@ -0,0 +1,175 @@
+/*
+ * v4l2-rect.h - v4l2_rect helper functions
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#ifndef _V4L2_RECT_H_
+#define _V4L2_RECT_H_
+
+#include 
+
+/**
+ * v4l2_rect_set_size_to() - copy the width/height values.
+ * @r: rect whose width and height fields will be set
+ * @size: rect containing the width and height fields you need.
+ */
+static inline void v4l2_rect_set_size_to(struct v4l2_rect *r,
+const struct v4l2_rect *size)
+{
+   r->width = size->width;
+   r->height = size->height;
+}
+
+/**
+ * v4l2_rect_set_min_size() - width and height of r should be >= min_size.
+ * @r: rect whose width and height will be modified
+ * @min_size: rect containing the minimal width and height
+ */
+static inline void v4l2_rect_set_min_size(struct v4l2_rect *r,
+ const struct v4l2_rect *min_size)
+{
+   if (r->width < min_size->width)
+   r->width = min_size->width;
+   if (r->height < min_size->height)
+   r->height = min_size->height;
+}
+
+/**
+ * v4l2_rect_set_max_size() - width and height of r should be <= max_size
+ * @r: rect whose width and height will be modified
+ * @max_size: rect containing the maximum width and height
+ */
+static inline void v4l2_rect_set_max_size(struct v4l2_rect *r,
+ const struct v4l2_rect *max_size)
+{
+   if (r->width > max_size->width)
+   r->width = max_size->width;
+   if (r->height > max_size->height)
+   r->height = max_size->height;
+}
+
+/**
+ * v4l2_rect_map_inside()- r should be inside boundary.
+ * @r: rect that will be modified
+ * @boundary: rect containing the boundary for @r
+ */
+static inline void v4l2_rect_map_inside(struct v4l2_rect *r,
+   const struct v4l2_rect *boundary)
+{
+   v4l2_rect_set_max_size(r, boundary);


This approach favours size over position. I'm not sure if that's the best
approach in all cases. Well, it's up to the user in the end to set correct
parameters.


Correct. The reason is that size tends to have a bigger impact on setting up a 
pipeline
than position. So I try to keep the size if at all possible.


+   if (r->left < boundary->left)
+   r->left = boundary->left;
+   if (r->top < boundary->top)
+   r->top = boundary->top;
+   if (r->left + r->width > boundary->width)
+   r->left = boundary->width - r->width;
+   if (r->top + r->height > boundary->height)
+   r->top = boundary->height - r->height;
+}
+
+/**
+ * v4l2_rect_same_size() - return true if r1 has the same size as r2
+ * @r1: rectangle.
+ * @r2: rectangle.
+ *
+ * Return true if both rectangles have the same size.
+ */
+static inline bool v4l2_rect_same_size(const struct v4l2_rect *r1,
+  const struct v4l2_rect *r2)
+{
+   return r1->width == r2->width && r1->height == r2->height;
+}
+
+/**
+ *

Re: [PATCH 2/2] videobuf2-v4l2: Verify planes array in buffer dequeueing

2016-04-06 Thread Hans Verkuil 



On 04/06/2016 04:46 AM, Sakari Ailus wrote:

When a buffer is being dequeued using VIDIOC_DQBUF IOCTL, the exact buffer
which will be dequeued is not known until the buffer has been removed from
the queue. The number of planes is specific to a buffer, not to the queue.

This does lead to the situation where multi-plane buffers may be requested
and queued with n planes, but VIDIOC_DQBUF IOCTL may be passed an argument
struct with fewer planes.

__fill_v4l2_buffer() however uses the number of planes from the dequeued
videobuf2 buffer, overwriting kernel memory (the m.planes array allocated
in video_usercopy() in v4l2-ioctl.c)  if the user provided fewer
planes than the dequeued buffer had. Oops!

Fixes: b0e0e1f83de3 ("[media] media: videobuf2: Prepare to divide videobuf2")
Signed-off-by: Sakari Ailus 


Acked-by: Hans Verkuil 

Thanks,

Hans


---
  drivers/media/v4l2-core/videobuf2-v4l2.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 91f5521..8da7470 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -74,6 +74,11 @@ static int __verify_planes_array(struct vb2_buffer *vb, 
const struct v4l2_buffer
return 0;
  }

+static int __verify_planes_array_core(struct vb2_buffer *vb, const void *pb)
+{
+   return __verify_planes_array(vb, pb);
+}
+
  /**
   * __verify_length() - Verify that the bytesused value for each plane fits in
   * the plane length and that the data offset doesn't exceed the bytesused 
value.
@@ -437,6 +442,7 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb,
  }

  static const struct vb2_buf_ops v4l2_buf_ops = {
+   .verify_planes_array= __verify_planes_array_core,
.fill_user_buffer   = __fill_v4l2_buffer,
.fill_vb2_buffer= __fill_vb2_buffer,
.copy_timestamp = __copy_timestamp,


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] [media] media: Improve documentation for link_setup/link_modify

2016-04-06 Thread Mauro Carvalho Chehab 
Those callbacks are called with the media_device.graph_mutex hold.

Add a note about that, as the code called by those notifiers should
not be touching in the mutex.

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Sakari Ailus 
---
 include/media/media-device.h | 3 ++-
 include/media/media-entity.h | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/media/media-device.h b/include/media/media-device.h
index b21ef244ad3e..44563ec17d45 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -311,7 +311,8 @@ struct media_entity_notify {
  * @enable_source: Enable Source Handler function pointer
  * @disable_source: Disable Source Handler function pointer
  *
- * @link_notify: Link state change notification callback
+ * @link_notify: Link state change notification callback. This callback is
+ * Called with the graph_mutex hold.
  *
  * This structure represents an abstract high-level media device. It allows 
easy
  * access to entities and provides basic media device-level support. The
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 6dc9e4e8cbd4..0b16ebe36db7 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -179,6 +179,9 @@ struct media_pad {
  * @link_validate: Return whether a link is valid from the entity point of
  * view. The media_entity_pipeline_start() function
  * validates all links by calling this operation. Optional.
+ *
+ * Note: Those ioctls should not touch the struct media_device.@graph_mutex
+ * field, as they're called with it already hold.
  */
 struct media_entity_operations {
int (*link_setup)(struct media_entity *entity,
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] [media] media-device: get rid of the spinlock

2016-04-06 Thread Mauro Carvalho Chehab 
Right now, the lock schema for media_device struct is messy,
since sometimes, it is protected via a spin lock, while, for
media graph traversal, it is protected by a mutex.

Solve this conflict by always using a mutex.

As a side effect, this prevents a bug when the media notifiers
is called at atomic context, while running the notifier callback:

 BUG: sleeping function called from invalid context at mm/slub.c:1289
 in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe
 4 locks held by modprobe/3479:
 #0:  (>mutex){..}, at: [] __driver_attach+0xa3/0x160
 #1:  (>mutex){..}, at: [] __driver_attach+0xb1/0x160
 #2:  (register_mutex#5){+.+.+.}, at: [] 
usb_audio_probe+0x257/0x1c90 [snd_usb_audio]
 #3:  (&(>lock)->rlock){+.+.+.}, at: [] 
media_device_register_entity+0x1cb/0x700 [media]
 CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49
 Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
  8803b3f6f288 81933901 8803c4bae000
 8803c4bae5c8 8803b3f6f2b0 811c6af5 8803c4bae000
 8285d7f6 0509 8803b3f6f2f0 811c6ce5
 Call Trace:
 [] dump_stack+0x85/0xc4
 [] ___might_sleep+0x245/0x3a0
 [] __might_sleep+0x95/0x1a0
 [] kmem_cache_alloc_trace+0x20e/0x300
 [] ? media_add_link+0x4d/0x140 [media]
 [] media_add_link+0x4d/0x140 [media]
 [] media_create_pad_link+0xa1/0x600 [media]
 [] au0828_media_graph_notify+0x173/0x360 [au0828]
 [] ? media_gobj_create+0x1ba/0x480 [media]
 [] media_device_register_entity+0x3ab/0x700 [media]

Reviewed-by: Javier Martinez Canillas 
Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/media-device.c | 39 +--
 drivers/media/media-entity.c | 16 
 include/media/media-device.h |  6 +-
 3 files changed, 22 insertions(+), 39 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 6e43c95629ea..898a3cf814ba 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -90,18 +90,13 @@ static struct media_entity *find_entity(struct media_device 
*mdev, u32 id)
 
id &= ~MEDIA_ENT_ID_FLAG_NEXT;
 
-   spin_lock(>lock);
-
media_device_for_each_entity(entity, mdev) {
if (((media_entity_id(entity) == id) && !next) ||
((media_entity_id(entity) > id) && next)) {
-   spin_unlock(>lock);
return entity;
}
}
 
-   spin_unlock(>lock);
-
return NULL;
 }
 
@@ -431,6 +426,7 @@ static long media_device_ioctl(struct file *filp, unsigned 
int cmd,
struct media_device *dev = to_media_device(devnode);
long ret;
 
+   mutex_lock(>graph_mutex);
switch (cmd) {
case MEDIA_IOC_DEVICE_INFO:
ret = media_device_get_info(dev,
@@ -443,29 +439,24 @@ static long media_device_ioctl(struct file *filp, 
unsigned int cmd,
break;
 
case MEDIA_IOC_ENUM_LINKS:
-   mutex_lock(>graph_mutex);
ret = media_device_enum_links(dev,
(struct media_links_enum __user *)arg);
-   mutex_unlock(>graph_mutex);
break;
 
case MEDIA_IOC_SETUP_LINK:
-   mutex_lock(>graph_mutex);
ret = media_device_setup_link(dev,
(struct media_link_desc __user *)arg);
-   mutex_unlock(>graph_mutex);
break;
 
case MEDIA_IOC_G_TOPOLOGY:
-   mutex_lock(>graph_mutex);
ret = media_device_get_topology(dev,
(struct media_v2_topology __user *)arg);
-   mutex_unlock(>graph_mutex);
break;
 
default:
ret = -ENOIOCTLCMD;
}
+   mutex_unlock(>graph_mutex);
 
return ret;
 }
@@ -590,12 +581,12 @@ int __must_check media_device_register_entity(struct 
media_device *mdev,
if (!ida_pre_get(>entity_internal_idx, GFP_KERNEL))
return -ENOMEM;
 
-   spin_lock(>lock);
+   mutex_lock(>graph_mutex);
 
ret = ida_get_new_above(>entity_internal_idx, 1,
>internal_idx);
if (ret < 0) {
-   spin_unlock(>lock);
+   mutex_unlock(>graph_mutex);
return ret;
}
 
@@ -615,9 +606,6 @@ int __must_check media_device_register_entity(struct 
media_device *mdev,
(notify)->notify(entity, notify->notify_data);
}
 
-   spin_unlock(>lock);
-
-   mutex_lock(>graph_mutex);
if (mdev->entity_internal_idx_max
>= mdev->pm_count_walk.ent_enum.idx_max) {
struct media_entity_graph new = { .top = 0 };
@@ -680,9 +668,9 @@ void

Re: Non-coherent (streaming) contig-dma?

2016-04-06 Thread Sakari Ailus 
On Mon, Apr 04, 2016 at 02:53:29PM +0200, Krzysztof Hałasa wrote:
> Hi,
> 
> I know certain approaches had been tried to allow use of streaming DMA
> (dma_map_single() etc. - i.e., not coherent) in the media drivers, is
> there something which can be used at this point (for MMAP method)?
> 
> Coherent buffers on many systems are very slow (uncacheable), should
> i simply add/replace the necessary calls in dma-contig?
> 
> Any other options?
> 
> Is there any potential problem there?

I don't think there's a really good solution to the problem in upstream.

For what it's worth, the USERPTR buffers are allocated non-coherent, and the
cache is flushed when that's needed.

I have a patchset that makes it driver-selectable whether to request
coherent or non-coherent memory. I haven't had time to work on that for a
while, unfortunately, that work stalled in fixing a few drivers that access
the buffers using the CPU as well when they really should not do that.

I sent the set here under the subject "[RFC RESEND 00/11] vb2: Handle user
cache hints, allow drivers to choose cache coherency" last September.

If you don't need to access the buffers using the CPU, you could avoid
flushing the cache as well, but it requires patches from that set as well.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] v4l2-rect.h: new header with struct v4l2_rect helper functions.

2016-04-06 Thread Sakari Ailus 
Hi Mauro,

On Sun, Apr 03, 2016 at 12:42:42PM -0700, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This makes it easier to share this code with any driver that needs to
> manipulate the v4l2_rect datastructure.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  Documentation/DocBook/device-drivers.tmpl |   1 +
>  include/media/v4l2-rect.h | 175 
> ++
>  2 files changed, 176 insertions(+)
>  create mode 100644 include/media/v4l2-rect.h
> 
> diff --git a/Documentation/DocBook/device-drivers.tmpl 
> b/Documentation/DocBook/device-drivers.tmpl
> index 184f3c7..893b2ca 100644
> --- a/Documentation/DocBook/device-drivers.tmpl
> +++ b/Documentation/DocBook/device-drivers.tmpl
> @@ -233,6 +233,7 @@ X!Isound/sound_firmware.c
>  !Iinclude/media/v4l2-mediabus.h
>  !Iinclude/media/v4l2-mem2mem.h
>  !Iinclude/media/v4l2-of.h
> +!Iinclude/media/v4l2-rect.h
>  !Iinclude/media/v4l2-subdev.h
>  !Iinclude/media/videobuf2-core.h
>  !Iinclude/media/videobuf2-v4l2.h
> diff --git a/include/media/v4l2-rect.h b/include/media/v4l2-rect.h
> new file mode 100644
> index 000..c138557
> --- /dev/null
> +++ b/include/media/v4l2-rect.h
> @@ -0,0 +1,175 @@
> +/*
> + * v4l2-rect.h - v4l2_rect helper functions
> + *
> + * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
> reserved.
> + *
> + * This program is free software; you may redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
> +
> +#ifndef _V4L2_RECT_H_
> +#define _V4L2_RECT_H_
> +
> +#include 
> +
> +/**
> + * v4l2_rect_set_size_to() - copy the width/height values.
> + * @r: rect whose width and height fields will be set
> + * @size: rect containing the width and height fields you need.
> + */
> +static inline void v4l2_rect_set_size_to(struct v4l2_rect *r,
> +  const struct v4l2_rect *size)
> +{
> + r->width = size->width;
> + r->height = size->height;
> +}
> +
> +/**
> + * v4l2_rect_set_min_size() - width and height of r should be >= min_size.
> + * @r: rect whose width and height will be modified
> + * @min_size: rect containing the minimal width and height
> + */
> +static inline void v4l2_rect_set_min_size(struct v4l2_rect *r,
> +   const struct v4l2_rect *min_size)
> +{
> + if (r->width < min_size->width)
> + r->width = min_size->width;
> + if (r->height < min_size->height)
> + r->height = min_size->height;
> +}
> +
> +/**
> + * v4l2_rect_set_max_size() - width and height of r should be <= max_size
> + * @r: rect whose width and height will be modified
> + * @max_size: rect containing the maximum width and height
> + */
> +static inline void v4l2_rect_set_max_size(struct v4l2_rect *r,
> +   const struct v4l2_rect *max_size)
> +{
> + if (r->width > max_size->width)
> + r->width = max_size->width;
> + if (r->height > max_size->height)
> + r->height = max_size->height;
> +}
> +
> +/**
> + * v4l2_rect_map_inside()- r should be inside boundary.
> + * @r: rect that will be modified
> + * @boundary: rect containing the boundary for @r
> + */
> +static inline void v4l2_rect_map_inside(struct v4l2_rect *r,
> + const struct v4l2_rect *boundary)
> +{
> + v4l2_rect_set_max_size(r, boundary);

This approach favours size over position. I'm not sure if that's the best
approach in all cases. Well, it's up to the user in the end to set correct
parameters.

> + if (r->left < boundary->left)
> + r->left = boundary->left;
> + if (r->top < boundary->top)
> + r->top = boundary->top;
> + if (r->left + r->width > boundary->width)
> + r->left = boundary->width - r->width;
> + if (r->top + r->height > boundary->height)
> + r->top = boundary->height - r->height;
> +}
> +
> +/**
> + * v4l2_rect_same_size() - return true if r1 has the same size as r2
> + * @r1: rectangle.
> + * @r2: rectangle.
> + *
> + * Return true if both rectangles have the same size.
> + */
> +static inline bool v4l2_rect_same_size(const struct v4l2_rect *r1,
> +const struct v4l2_rect *r2)
> +{
> + return r1->width == r2->width && r1->height == r2->height;
> +}
> +
> +/**
> + *

Re: [PATCH 0/2] videobuf2: Fix kernel memory overwriting

2016-04-06 Thread Sakari Ailus 
Fixing Mauro's e-mail address...

On Wed, Apr 06, 2016 at 02:46:06PM +0300, Sakari Ailus wrote:
> Hi all,
> 
> In multi-planar API, the buffer length and m.planes fields are checked
> against the vb2 buffer before passing the buffer on to the core, but
> commit b0e0e1f83de31aa0428c38b692c590cc0ecd3f03 removed this check from
> VIDIOC_DQBUF path. This leads to kernel memory overwriting in certain
> cases.
> 
> This affects only v4.4 and newer and a very few drivers which use the
> multi-planar API. Due to the very limited scope of the issue this is not
> seen to require special handling.
> 
> The patches should be applied to the stable series, I'll add cc stable
> in the pull request.
> 
> -- 
> Kind regards,
> Sakari
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] videobuf2: Fix kernel memory overwriting

2016-04-06 Thread Sakari Ailus 
Hi all,

In multi-planar API, the buffer length and m.planes fields are checked
against the vb2 buffer before passing the buffer on to the core, but
commit b0e0e1f83de31aa0428c38b692c590cc0ecd3f03 removed this check from
VIDIOC_DQBUF path. This leads to kernel memory overwriting in certain
cases.

This affects only v4.4 and newer and a very few drivers which use the
multi-planar API. Due to the very limited scope of the issue this is not
seen to require special handling.

The patches should be applied to the stable series, I'll add cc stable
in the pull request.

-- 
Kind regards,
Sakari

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] videobuf2-core: Check user space planes array in dqbuf

2016-04-06 Thread Sakari Ailus 
The number of planes in videobuf2 is specific to a buffer. In order to
verify that the planes array provided by the user is long enough, a new
vb2_buf_op is required.

Call __verify_planes_array() when the dequeued buffer is known. Return an
error to the caller if there was one, otherwise remove the buffer from the
done list.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-core.c | 10 +-
 include/media/videobuf2-core.h   |  4 
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 5d016f4..2169544 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1645,7 +1645,7 @@ static int __vb2_wait_for_done_vb(struct vb2_queue *q, 
int nonblocking)
  * Will sleep if required for nonblocking == false.
  */
 static int __vb2_get_done_vb(struct vb2_queue *q, struct vb2_buffer **vb,
-   int nonblocking)
+void *pb, int nonblocking)
 {
unsigned long flags;
int ret;
@@ -1666,10 +1666,10 @@ static int __vb2_get_done_vb(struct vb2_queue *q, 
struct vb2_buffer **vb,
/*
 * Only remove the buffer from done_list if v4l2_buffer can handle all
 * the planes.
-* Verifying planes is NOT necessary since it already has been checked
-* before the buffer is queued/prepared. So it can never fail.
 */
-   list_del(&(*vb)->done_entry);
+   ret = call_bufop(q, verify_planes_array, *vb, pb);
+   if (!ret)
+   list_del(&(*vb)->done_entry);
spin_unlock_irqrestore(>done_lock, flags);
 
return ret;
@@ -1748,7 +1748,7 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int 
*pindex, void *pb,
struct vb2_buffer *vb = NULL;
int ret;
 
-   ret = __vb2_get_done_vb(q, , nonblocking);
+   ret = __vb2_get_done_vb(q, , pb, nonblocking);
if (ret < 0)
return ret;
 
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 8a0f55b..e2b1773 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -375,6 +375,9 @@ struct vb2_ops {
 /**
  * struct vb2_ops - driver-specific callbacks
  *
+ * @verify_planes_array:Verify that a given user space structure contains
+ * enough planes for the buffer. This is called
+ * for each dequeued buffer.
  * @fill_user_buffer:  given a vb2_buffer fill in the userspace structure.
  * For V4L2 this is a struct v4l2_buffer.
  * @fill_vb2_buffer:   given a userspace structure, fill in the vb2_buffer.
@@ -384,6 +387,7 @@ struct vb2_ops {
  * the vb2_buffer struct.
  */
 struct vb2_buf_ops {
+   int (*verify_planes_array)(struct vb2_buffer *vb, const void *pb);
void (*fill_user_buffer)(struct vb2_buffer *vb, void *pb);
int (*fill_vb2_buffer)(struct vb2_buffer *vb, const void *pb,
struct vb2_plane *planes);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] videobuf2-v4l2: Verify planes array in buffer dequeueing

2016-04-06 Thread Sakari Ailus 
When a buffer is being dequeued using VIDIOC_DQBUF IOCTL, the exact buffer
which will be dequeued is not known until the buffer has been removed from
the queue. The number of planes is specific to a buffer, not to the queue.

This does lead to the situation where multi-plane buffers may be requested
and queued with n planes, but VIDIOC_DQBUF IOCTL may be passed an argument
struct with fewer planes.

__fill_v4l2_buffer() however uses the number of planes from the dequeued
videobuf2 buffer, overwriting kernel memory (the m.planes array allocated
in video_usercopy() in v4l2-ioctl.c)  if the user provided fewer
planes than the dequeued buffer had. Oops!

Fixes: b0e0e1f83de3 ("[media] media: videobuf2: Prepare to divide videobuf2")
Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 91f5521..8da7470 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -74,6 +74,11 @@ static int __verify_planes_array(struct vb2_buffer *vb, 
const struct v4l2_buffer
return 0;
 }
 
+static int __verify_planes_array_core(struct vb2_buffer *vb, const void *pb)
+{
+   return __verify_planes_array(vb, pb);
+}
+
 /**
  * __verify_length() - Verify that the bytesused value for each plane fits in
  * the plane length and that the data offset doesn't exceed the bytesused 
value.
@@ -437,6 +442,7 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb,
 }
 
 static const struct vb2_buf_ops v4l2_buf_ops = {
+   .verify_planes_array= __verify_planes_array_core,
.fill_user_buffer   = __fill_v4l2_buffer,
.fill_vb2_buffer= __fill_vb2_buffer,
.copy_timestamp = __copy_timestamp,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 14/30] media: use parity8 in vivid-vbi-gen.c

2016-04-06 Thread zengzhaoxiu 
From: Zhaoxiu Zeng 

Signed-off-by: Zhaoxiu Zeng 
---
 drivers/media/platform/vivid/vivid-vbi-gen.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-vbi-gen.c 
b/drivers/media/platform/vivid/vivid-vbi-gen.c
index a2159de..d5ba0fc 100644
--- a/drivers/media/platform/vivid/vivid-vbi-gen.c
+++ b/drivers/media/platform/vivid/vivid-vbi-gen.c
@@ -175,14 +175,9 @@ static const u8 vivid_cc_sequence2[30] = {
0x14, 0x2f, /* End of Caption */
 };
 
-static u8 calc_parity(u8 val)
+static inline u8 calc_parity(u8 val)
 {
-   unsigned i;
-   unsigned tot = 0;
-
-   for (i = 0; i < 7; i++)
-   tot += (val & (1 << i)) ? 1 : 0;
-   return val | ((tot & 1) ? 0 : 0x80);
+   return (!parity8(val) << 7) | val;
 }
 
 static void vivid_vbi_gen_set_time_of_day(u8 *packet)
-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 15/30] media: use parity functions in saa7115

2016-04-06 Thread zengzhaoxiu 
From: Zhaoxiu Zeng 

Signed-off-by: Zhaoxiu Zeng 
---
 drivers/media/i2c/saa7115.c | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
index d2a1ce2..4c22df8 100644
--- a/drivers/media/i2c/saa7115.c
+++ b/drivers/media/i2c/saa7115.c
@@ -672,15 +672,6 @@ static const unsigned char saa7115_init_misc[] = {
0x00, 0x00
 };
 
-static int saa711x_odd_parity(u8 c)
-{
-   c ^= (c >> 4);
-   c ^= (c >> 2);
-   c ^= (c >> 1);
-
-   return c & 1;
-}
-
 static int saa711x_decode_vps(u8 *dst, u8 *p)
 {
static const u8 biphase_tbl[] = {
@@ -733,7 +724,6 @@ static int saa711x_decode_wss(u8 *p)
static const int wss_bits[8] = {
0, 0, 0, 1, 0, 1, 1, 1
};
-   unsigned char parity;
int wss = 0;
int i;
 
@@ -745,11 +735,8 @@ static int saa711x_decode_wss(u8 *p)
return -1;
wss |= b2 << i;
}
-   parity = wss & 15;
-   parity ^= parity >> 2;
-   parity ^= parity >> 1;
 
-   if (!(parity & 1))
+   if (!parity4(wss))
return -1;
 
return wss;
@@ -1235,7 +1222,7 @@ static int saa711x_decode_vbi_line(struct v4l2_subdev 
*sd, struct v4l2_decode_vb
vbi->type = V4L2_SLICED_TELETEXT_B;
break;
case 4:
-   if (!saa711x_odd_parity(p[0]) || !saa711x_odd_parity(p[1]))
+   if (!parity8(p[0]) || !parity8(p[1]))
return 0;
vbi->type = V4L2_SLICED_CAPTION_525;
break;
-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC v2 1/2] media: platform: transfer format translations to soc_mediabus

2016-04-06 Thread Robert Jarzmik 
Guennadi Liakhovetski  writes:

Hi Guennadi,
> Not sure I understand, what should the purpose of this patch be?
See in [1].

> Why do you want to move some function(s) from one file to another?  And you
> aren't even calling the new soc_mbus_build_fmts_xlate() function
I'm calling it in pxa_camera_build_formats() in patch 2/2.

> and you aren't replacing the currently used analogous
> soc_camera_init_user_formats() function.
I'm doing that in patch 2/2.

> Or was this patch not-to-be-reviewed?
Actually these 2 patches are designed to be discussion openers :)
For me, their purpose is to expose the transition of pxa_camera out of
soc_camera and see if the chosen path is good, or if there exists a better one.

In other words, these patches show that :
 - in a first stage, soc_mediabus should be kept [1]
   => at least for formats translation (soc_mbus_build_fmts_xlate())
   => and for used formats by sensors
   => this is why patch 1/1 exists

 - the conversion almost doesn't touch the pxa_camera_() core functions (IP
   manipulation), which is good, and only touch the upper layer

 - that soc_mediabus adherence removal will be another task

 - the amount of code which is shifted from soc_camera to pxa_camera

 - the functionalities that are lost through conversion which should be readded
   later
   => cropping is one
   => pixel clock sensing is another one

All in all, before submitting patch for real, ie. not in RFC mode, I wanted to
be sure the proposed conversion is sound, and compare to other drivers
conversion to see if we were going in the same direction.

As to whether this patch should be reviewed or not, I'd say that I was just
expecting to have an "that might be the way to go" or "NAK, wrong patch, let's
do something else instead".

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html