linux-stable.git/drivers/media, branch v5.0.4

media: vimc: Add vimc-streamer for stream control

2019-03-23T19:11:39+00:00

commit adc589d2a20808fb99d46a78175cd023f2040338 upstream.

Add a linear pipeline logic for the stream control. It's created by
walking backwards on the entity graph. When the stream starts it will
simply loop through the pipeline calling the respective process_frame
function of each entity.

Fixes: f2fe89061d797 ("vimc: Virtual Media Controller core, capture
and sensor")

Cc: stable@vger.kernel.org # for v4.20
Signed-off-by: Lucas A. M. Magalhães 
Acked-by: Helen Koike 
Signed-off-by: Hans Verkuil 
[hverkuil-cisco@xs4all.nl: fixed small space-after-tab issue in the patch]
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Avoid NULL pointer dereference at the end of streaming

2019-03-23T19:11:39+00:00

commit 9dd0627d8d62a7ddb001a75f63942d92b5336561 upstream.

The UVC video driver converts the timestamp from hardware specific unit
to one known by the kernel at the time when the buffer is dequeued. This
is fine in general, but the streamoff operation consists of the
following steps (among other things):

1. uvc_video_clock_cleanup --- the hardware clock sample array is
   released and the pointer to the array is set to NULL,

2. buffers in active state are returned to the user and

3. buf_finish callback is called on buffers that are prepared.
   buf_finish includes calling uvc_video_clock_update that accesses the
   hardware clock sample array.

The above is serialised by a queue specific mutex. Address the problem
by skipping the clock conversion if the hardware clock sample array is
already released.

Fixes: 9c0863b1cc48 ("[media] vb2: call buf_finish from __queue_cancel")

Reported-by: Chiranjeevi Rapolu 
Tested-by: Chiranjeevi Rapolu 
Signed-off-by: Sakari Ailus 
Cc: stable@vger.kernel.org
Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: sun6i: Fix CSI regmap's max_register

2019-03-23T19:11:38+00:00

commit d31b282e2c0de9c7fb113516820340251f03a625 upstream.

max_register is currently set to 0x1000. This is beyond the mapped
address range of the hardware, so attempts to dump the regmap from
debugfs would trigger a kernel exception.

Furthermore, the useful registers only occupy a small section at the
beginning of the full range. Change the value to 0x9c, the last known
register on the V3s and H3.

On the A31, the register range is extended to support additional
capture channels. Since this is not yet supported, ignore it for now.

Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")

Cc: 
Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: lgdt330x: fix lock status reporting

2019-03-23T19:11:38+00:00

commit 1b4fd9de6ec7f3722c2b3e08cc5ad171c11f93be upstream.

A typo in code cleanup commit db9c1007bc07 ("media: lgdt330x: do
some cleanups at status logic") broke the FE_HAS_LOCK reporting
for 3303 chips by inadvertently modifying the register mask.

The broken lock status is critial as it prevents video capture
cards from reporting signal strength, scanning for channels,
and capturing video.

Fix regression by reverting mask change.

Cc: stable@vger.kernel.org # Kernel 4.17+
Fixes: db9c1007bc07 ("media: lgdt330x: do some cleanups at status logic")
Signed-off-by: Nick French 
Reviewed-by: Laurent Pinchart 
Tested-by: Adam Stylinski 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: cx25840: mark pad sig_types to fix cx231xx init

2019-03-23T19:11:34+00:00

commit 46c039d06b6ecabb94bd16c3a999b28dc83b79ce upstream.

Without this, we get failures like this when the kernel attempts to
initialize a cx231xx device:

	[16046.153653] cx231xx 3-1.2:1.1: New device Hauppauge Hauppauge Device @ 480 Mbps (2040:c200) with 6 interfaces
	[16046.153900] cx231xx 3-1.2:1.1: can't change interface 3 alt no. to 3: Max. Pkt size = 0
	[16046.153907] cx231xx 3-1.2:1.1: Identified as Hauppauge USB Live 2 (card=9)
	[16046.154350] i2c i2c-11: Added multiplexed i2c bus 13
	[16046.154379] i2c i2c-11: Added multiplexed i2c bus 14
	[16046.267194] cx25840 10-0044: cx23102 A/V decoder found @ 0x88 (cx231xx #0-0)
	[16048.424551] cx25840 10-0044: loaded v4l-cx231xx-avcore-01.fw firmware (16382 bytes)
	[16048.463224] cx231xx 3-1.2:1.1: v4l2 driver version 0.0.3
	[16048.567878] cx231xx 3-1.2:1.1: Registered video device video2 [v4l2]
	[16048.568001] cx231xx 3-1.2:1.1: Registered VBI device vbi0
	[16048.568419] cx231xx 3-1.2:1.1: audio EndPoint Addr 0x83, Alternate settings: 3
	[16048.568425] cx231xx 3-1.2:1.1: video EndPoint Addr 0x84, Alternate settings: 5
	[16048.568431] cx231xx 3-1.2:1.1: VBI EndPoint Addr 0x85, Alternate settings: 2
	[16048.568436] cx231xx 3-1.2:1.1: sliced CC EndPoint Addr 0x86, Alternate settings: 2
	[16048.568448] usb 3-1.2: couldn't get decoder output pad for V4L I/O
	[16048.568453] cx231xx 3-1.2:1.1: V4L2 device vbi0 deregistered
	[16048.568579] cx231xx 3-1.2:1.1: V4L2 device video2 deregistered
	[16048.569001] cx231xx: probe of 3-1.2:1.1 failed with error -22

Likely a regession since Commit 9d6d20e652c0
("media: v4l2-mc: switch it to use the new approach to setup pipelines")
(v4.19-rc1-100-g9d6d20e652c0), which introduced the use of
PAD_SIGNAL_DV within v4l2_mc_create_media_graph().

This also modifies cx25840 to remove the VBI pad, matching the action
taken in Commit 092a37875a22 ("media: v4l2: remove VBI output pad").

Fixes: 9d6d20e652c0 ("media: v4l2-mc: switch it to use the new approach to setup pipelines")

Cc: stable@vger.kernel.org
Signed-off-by: Cody P Schafer 
Tested-by: Hans Verkuil 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: i2c: ov5640: Fix post-reset delay

2019-03-23T19:11:25+00:00

commit 1d4c41f3d887bcd66e82cb2fda124533dad8808a upstream.

According to the ov5640 specification (2.7 power up sequence), host can
access the sensor's registers 20ms after reset. Trying to access them
before leads to undefined behavior and result in sporadic initialization
errors.

Signed-off-by: Loic Poulain 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
Cc: Adam Ford 
Signed-off-by: Greg Kroah-Hartman

media: Revert "media: rc: some events are dropped by userspace"

2019-03-13T21:01:31+00:00

commit 05f0edadcc5fccdfc0676825b3e70e75dc0a8a84 upstream.

When an rc device is created, we do not know what key codes it will
support, since a new keymap might be loaded at some later point. So,
we set all keybit in the input device.

The uevent for the input device includes all the key codes, of which
there are now 768. This overflows the size of the uevent
(UEVENT_BUFFER_SIZE) and no event is generated.

Revert for now until we figure out a different solution.

This reverts commit fec225a04330d0f222d24feb5bea045526031675.

Cc:  # 4.20+
Reported-by: Christian Holpert 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Fix 'type' check leading to overflow

2019-03-13T21:01:29+00:00

commit 47bb117911b051bbc90764a8bff96543cbd2005f upstream.

When initially testing the Camera Terminal Descriptor wTerminalType
field (buffer[4]), no mask is used. Later in the function, the MSB is
overloaded to store the descriptor subtype, and so a mask of 0x7fff
is used to check the type.

If a descriptor is specially crafted to set this overloaded bit in the
original wTerminalType field, the initial type check will fail (falling
through, without adjusting the buffer size), but the later type checks
will pass, assuming the buffer has been made suitably large, causing an
overflow.

Avoid this problem by checking for the MSB in the wTerminalType field.
If the bit is set, assume the descriptor is bad, and abort parsing it.

Originally reported here:
https://groups.google.com/forum/#!topic/syzkaller/Ot1fOE6v1d8
A similar (non-compiling) patch was provided at that time.

Reported-by: syzbot 
Signed-off-by: Alistair Strachan 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: vim2m: only cancel work if it is for right context

2019-01-16T16:13:25+00:00

cancel_delayed_work_sync() was called for any queue, but it should only
be called for the queue that is associated with the currently running job.

Otherwise, if two filehandles are streaming at the same time, then closing the
first will cancel the work which might still be running for a job from the
second filehandle. As a result the second filehandle will never be able to
finish the job and an attempt to stop streaming on that second filehandle will
stall.

Fixes: 52117be68b82 ("media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work")

Signed-off-by: Hans Verkuil 
Cc:       # for v4.20 and up
Signed-off-by: Mauro Carvalho Chehab

media: v4l: ioctl: Validate num_planes for debug messages

2019-01-16T16:12:38+00:00

The num_planes field in struct v4l2_pix_format_mplane is used in a loop
before validating it. As the use is printing a debug message in this case,
just cap the value to the maximum allowed.

Signed-off-by: Sakari Ailus 
Cc: stable@vger.kernel.org
Reviewed-by: Thierry Reding 
Signed-off-by: Hans Verkuil 
Cc:       # for v4.12 and up
Signed-off-by: Mauro Carvalho Chehab