cron job: media_tree daily build: ERRORS

2018-07-29 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:   Mon Jul 30 05:00:10 CEST 2018
media-tree git hash:4faeaf9c0f4581667ce5826f9c90c4fd463ef086
media_build git hash:   5d2bedd1c9c770d03c3e95282f55fe9979d26248
v4l-utils git hash: 5e8d31abc6f531ef0bc0fc563d5311602a395685
edid-decode git hash:   ab18befbcacd6cd4dff63faa82e32700369d6f25
gcc version:i686-linux-gcc (GCC) 8.1.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware:  x86_64
host os:4.16.0-1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-i686: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-i686: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-i686: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.101-i686: OK
linux-3.0.101-x86_64: OK
linux-3.1.10-i686: OK
linux-3.1.10-x86_64: OK
linux-3.2.102-i686: ERRORS
linux-3.2.102-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.113-i686: OK
linux-3.4.113-x86_64: OK
linux-3.5.7-i686: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-i686: OK
linux-3.6.11-x86_64: OK
linux-3.7.10-i686: OK
linux-3.7.10-x86_64: OK
linux-3.8.13-i686: OK
linux-3.8.13-x86_64: OK
linux-3.9.11-i686: OK
linux-3.9.11-x86_64: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.57-i686: OK
linux-3.16.57-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.115-i686: OK
linux-3.18.115-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.140-i686: OK
linux-4.4.140-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.112-i686: OK
linux-4.9.112-x86_64: OK
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: OK
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: OK
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: OK
linux-4.13.16-i686: OK
linux-4.13.16-x86_64: OK
linux-4.14.55-i686: OK
linux-4.14.55-x86_64: OK
linux-4.15.18-i686: OK
linux-4.15.18-x86_64: OK
linux-4.16.18-i686: OK
linux-4.16.18-x86_64: OK
linux-4.17.6-i686: OK
linux-4.17.6-x86_64: OK
linux-4.18-rc4-i686: OK
linux-4.18-rc4-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


[GIT FIXES FOR v4.18] out of bounds memory read

2018-07-29 Thread Sean Young
Hi Mauro,

Please pull this fix for v4.18, if possible.

Thanks,

Sean

The following changes since commit 92cab799bbc6fa1fca84bd1692285a5f926c17e9:

  media: bpf: ensure bpf program is freed on detach (2018-07-26 08:39:18 -0400)

are available in the Git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.18g

for you to fetch changes up to 0922465cba37c45c1db0786b7fa1ea822bd647a5:

  media: rc: read out of bounds if bpf reports high protocol number (2018-07-29 
16:31:45 +0100)


Sean Young (1):
  media: rc: read out of bounds if bpf reports high protocol number

 drivers/media/rc/rc-main.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)


Re: [PATCH] uvcvideo: add a D4M camera description

2018-07-29 Thread Laurent Pinchart
Hi Guennadi,

Thank you for the patch.

On Saturday, 23 December 2017 13:11:00 EEST Guennadi Liakhovetski wrote:
> From: Guennadi Liakhovetski 
> 
> D4M is a mobile model from the D4XX family of Intel RealSense cameras.
> This patch adds a descriptor for it, which enables reading per-frame
> metadata from it.
> 
> Signed-off-by: Guennadi Liakhovetski 
> ---
>  Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst | 202 +++
>  drivers/media/usb/uvc/uvc_driver.c|  11 ++
>  include/uapi/linux/videodev2.h|   1 +
>  3 files changed, 214 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst
> 
> diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst
> b/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst new file mode 100644
> index 000..950780d
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst
> @@ -0,0 +1,202 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _v4l2-meta-fmt-d4xx:
> +
> +***
> +V4L2_META_FMT_D4XX ('D4XX')
> +***
> +
> +D4XX Metadata

How about "Intel D4xx UVC Cameras Metadata" ?

> +
> +
> +Description
> +===
> +
> +D4XX (D435 and other) cameras include per-frame metadata in their UVC
> payload

Should this be "Intel D4XX" ?

> +headers, following the Microsoft(R) UVC extension proposal [1_]. That
> means,
> +that the private D4XX metadata, following the standard UVC header, is
> organised
> +in blocks. D4XX cameras implement several standard block types, proposed by
> +Microsoft, and several proprietary ones. Supported standard metadata types
> +include MetadataId_CaptureStats (ID 3), MetadataId_CameraExtrinsics (ID 4),
> and
> +MetadataId_CameraIntrinsics (ID 5). For their description see [1_].

Does "including" mean that the list isn't exhaustive and that other standard 
types could be returned too ? If so, would it be possible to get an exhaustive 
list ? And if the list is exhaustive, could you word this paragraph to make 
that clear ?

> This
> +document describes proprietary metadata types, used by DS4XX cameras.

Is it D4XX or DS4XX ?

> +V4L2_META_FMT_D4XX buffers follow the metadata buffer layout of
> +V4L2_META_FMT_UVC with the only difference, that it also includes
> proprietary
> +payload header data. D4XX cameras use bulk transfers and only send one
> payload
> +per frame, therefore their headers cannot be larger than 255 bytes.
> +
> +Below are proprietary Microsoft style metadata types, used by D4XX cameras,
> +where all fields are in little endian order:
> +
> +.. flat-table:: D4XX metadata
> +:widths: 1 4
> +:header-rows:  1
> +:stub-columns: 0
> +
> +* - Field
> +  - Description
> +* - :cspan:`1` *Depth Control*
> +* - __u32 ID
> +  - 0x8000
> +* - __u32 Size
> +  - Size in bytes (currently 56)
> +* - __u32 Version
> +  - Version of the struct

What is this field used for ?

> +* - __u32 Flags
> +  - A bitmask of flags: see [2_] below
> +* - __u32 Gain
> +  - Manual gain value

What is the gain unit ?

> +* - __u32 Exposure
> +  - Manual exposure time in microseconds

When auto-exposure is enabled, does this reflect the actual exposure time used 
to capture the image ? If so I'd name the field just "exposure time", and 
expand the document to explain this. Maybe something like

"Exposure time (in microseconds) that was used to capture the frame."

It would also be useful to explain what happens when auto-exposure is 
disabled.

This comment applies to the gain as well.

> +* - __u32 Laser power
> +  - Power of the laser LED 0-360, used for depth measurement
> +* - __u32 AE mode
> +  - 0: manual; 1: automatic exposure
> +* - __u32 Exposure priority
> +  - Exposure priority value: 0 - constant frameerate

s/frameerate/frame rate/

No other value than 0 is valid ?

> +* - __u32 AE ROI left
> +  - Left border of the AE Region of Interest
> +* - __u32 AE ROI right
> +  - Right border of the AE Region of Interest
> +* - __u32 AE ROI top
> +  - Top border of the AE Region of Interest
> +* - __u32 AE ROI bottom
> +  - Bottom border of the AE Region of Interest

What are the units and range for those fields ?

> +* - __u32 Preset
> +  - Preset selector value

Could you elaborate a bit on what the preset selector value is ?

> +* - __u32 Laser mode
> +  - 0: off, 1: on
> +* - :cspan:`1` *Capture Timing*
> +* - __u32 ID
> +  - 0x8001
> +* - __u32 Size
> +  - Size in bytes (currently 40)
> +* - __u32 Version
> +  - Version of the struct
> +* - __u32 Flags
> +  - A bitmask of flags: see [3_] below
> +* - __u32 Frame counter
> +  - Monotonically increasing counter

That's interesting. Does it increase by exactly one for every frame ? I think 
it would be useful to document that.

> +* - __u32 Optical time
> +  -