<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/media, branch linux-5.6.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>media: videobuf2-dma-contig: fix bad kfree in vb2_dma_contig_clear_max_seg_size</title>
<updated>2020-06-17T14:42:04+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2020-05-27T08:23:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bbc0238e79c2bb2361047e178fb64f36626fd3c5'/>
<id>bbc0238e79c2bb2361047e178fb64f36626fd3c5</id>
<content type='text'>
commit 0d9668721311607353d4861e6c32afeb272813dc upstream.

Commit 9495b7e92f716ab2bd6814fab5e97ab4a39adfdd ("driver core: platform:
Initialize dma_parms for platform devices") in v5.7-rc5 causes
vb2_dma_contig_clear_max_seg_size() to kfree memory that was not
allocated by vb2_dma_contig_set_max_seg_size().

The assumption in vb2_dma_contig_set_max_seg_size() seems to be that
dev-&gt;dma_parms is always NULL when the driver is probed, and the case
where dev-&gt;dma_parms has bee initialized by someone else than the driver
(by calling vb2_dma_contig_set_max_seg_size) will cause a failure.

All the current users of these functions are platform devices, which now
always have dma_parms set by the driver core. To fix the issue for v5.7,
make vb2_dma_contig_set_max_seg_size() return an error if dma_parms is
NULL to be on the safe side, and remove the kfree code from
vb2_dma_contig_clear_max_seg_size().

For v5.8 we should remove the two functions and move the
dma_set_max_seg_size() calls into the drivers.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Fixes: 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices")
Cc: stable@vger.kernel.org
Acked-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Reviewed-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0d9668721311607353d4861e6c32afeb272813dc upstream.

Commit 9495b7e92f716ab2bd6814fab5e97ab4a39adfdd ("driver core: platform:
Initialize dma_parms for platform devices") in v5.7-rc5 causes
vb2_dma_contig_clear_max_seg_size() to kfree memory that was not
allocated by vb2_dma_contig_set_max_seg_size().

The assumption in vb2_dma_contig_set_max_seg_size() seems to be that
dev-&gt;dma_parms is always NULL when the driver is probed, and the case
where dev-&gt;dma_parms has bee initialized by someone else than the driver
(by calling vb2_dma_contig_set_max_seg_size) will cause a failure.

All the current users of these functions are platform devices, which now
always have dma_parms set by the driver core. To fix the issue for v5.7,
make vb2_dma_contig_set_max_seg_size() return an error if dma_parms is
NULL to be on the safe side, and remove the kfree code from
vb2_dma_contig_clear_max_seg_size().

For v5.8 we should remove the two functions and move the
dma_set_max_seg_size() calls into the drivers.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Fixes: 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices")
Cc: stable@vger.kernel.org
Acked-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Reviewed-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: ti-vpe: cal: fix a kernel oops when unloading module</title>
<updated>2020-04-17T14:13:27+00:00</updated>
<author>
<name>Benoit Parrot</name>
<email>bparrot@ti.com</email>
</author>
<published>2020-03-06T13:08:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8f1d061d754844b463cf592c982eee1ae674c2c1'/>
<id>8f1d061d754844b463cf592c982eee1ae674c2c1</id>
<content type='text'>
commit 80264809ea0a3fd2ee8251f31a9eb85d2c3fc77e upstream.

After the switch to use v4l2_async_notifier_add_subdev() and
v4l2_async_notifier_cleanup(), unloading the ti_cal module would cause a
kernel oops.

This was root cause to the fact that v4l2_async_notifier_cleanup() tries
to kfree the asd pointer passed into v4l2_async_notifier_add_subdev().

In our case the asd reference was from a statically allocated struct.
So in effect v4l2_async_notifier_cleanup() was trying to free a pointer
that was not kalloc.

So here we switch to using a kzalloc struct instead of a static one.
To achieve this we re-order some of the calls to prevent asd allocation
from leaking.

Fixes: d079f94c9046 ("media: platform: Switch to v4l2_async_notifier_add_subdev")
Cc: stable@vger.kernel.org
Signed-off-by: Benoit Parrot &lt;bparrot@ti.com&gt;
Reviewed-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 80264809ea0a3fd2ee8251f31a9eb85d2c3fc77e upstream.

After the switch to use v4l2_async_notifier_add_subdev() and
v4l2_async_notifier_cleanup(), unloading the ti_cal module would cause a
kernel oops.

This was root cause to the fact that v4l2_async_notifier_cleanup() tries
to kfree the asd pointer passed into v4l2_async_notifier_add_subdev().

In our case the asd reference was from a statically allocated struct.
So in effect v4l2_async_notifier_cleanup() was trying to free a pointer
that was not kalloc.

So here we switch to using a kzalloc struct instead of a static one.
To achieve this we re-order some of the calls to prevent asd allocation
from leaking.

Fixes: d079f94c9046 ("media: platform: Switch to v4l2_async_notifier_add_subdev")
Cc: stable@vger.kernel.org
Signed-off-by: Benoit Parrot &lt;bparrot@ti.com&gt;
Reviewed-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: ti-vpe: cal: fix disable_irqs to only the intended target</title>
<updated>2020-04-17T14:13:27+00:00</updated>
<author>
<name>Benoit Parrot</name>
<email>bparrot@ti.com</email>
</author>
<published>2020-03-02T13:56:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ec00e4a8d89f9c90137f06a5022379e4c2766333'/>
<id>ec00e4a8d89f9c90137f06a5022379e4c2766333</id>
<content type='text'>
commit 1db56284b9da9056093681f28db48a09a243274b upstream.

disable_irqs() was mistakenly disabling all interrupts when called.
This cause all port stream to stop even if only stopping one of them.

Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Benoit Parrot &lt;bparrot@ti.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1db56284b9da9056093681f28db48a09a243274b upstream.

disable_irqs() was mistakenly disabling all interrupts when called.
This cause all port stream to stop even if only stopping one of them.

Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Benoit Parrot &lt;bparrot@ti.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: venus: firmware: Ignore secure call error on first resume</title>
<updated>2020-04-17T14:13:26+00:00</updated>
<author>
<name>Stanimir Varbanov</name>
<email>stanimir.varbanov@linaro.org</email>
</author>
<published>2020-03-04T10:09:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=28a2f5c6283f86b2649a5c3db3b94373bc30d90d'/>
<id>28a2f5c6283f86b2649a5c3db3b94373bc30d90d</id>
<content type='text'>
commit 2632e7b618a7730969f9782593c29ca53553aa22 upstream.

With the latest cleanup in qcom scm driver the secure monitor
call for setting the remote processor state returns EINVAL when
it is called for the first time and after another scm call
auth_and_reset. The error returned from scm call could be ignored
because the state transition is already done in auth_and_reset.

Acked-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Signed-off-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2632e7b618a7730969f9782593c29ca53553aa22 upstream.

With the latest cleanup in qcom scm driver the secure monitor
call for setting the remote processor state returns EINVAL when
it is called for the first time and after another scm call
auth_and_reset. The error returned from scm call could be ignored
because the state transition is already done in auth_and_reset.

Acked-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Signed-off-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: venus: cache vb payload to be used by clock scaling</title>
<updated>2020-04-17T14:13:26+00:00</updated>
<author>
<name>Stanimir Varbanov</name>
<email>stanimir.varbanov@linaro.org</email>
</author>
<published>2020-02-13T09:55:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=03fa57dd4d94764e3ee384b65f33c1fe9bb57d01'/>
<id>03fa57dd4d94764e3ee384b65f33c1fe9bb57d01</id>
<content type='text'>
commit fd1ee315dcd4a0f913a74939eb88f6d9b0bd9250 upstream.

Instead of iterate over previously queued buffers in clock
scaling code do cache the payload in instance context structure
for later use when calculating new clock rate.

This will avoid to use spin locks during buffer list iteration
in clock_scaling.

This fixes following kernel Oops:

 Unable to handle kernel paging request at virtual address deacfffffffffd6c
 Mem abort info:
   ESR = 0x96000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
 Data abort info:
   ISV = 0, ISS = 0x00000004
   CM = 0, WnR = 0
 [deacfffffffffd6c] address between user and kernel address ranges
 Internal error: Oops: 96000004 [#1] PREEMPT SMP
 CPU: 7 PID: 5763 Comm: V4L2DecoderThre Tainted: G S      W         5.4.11 #8
 pstate: 20400009 (nzCv daif +PAN -UAO)
 pc : load_scale_v4+0x4c/0x2bc [venus_core]
 lr : session_process_buf+0x18c/0x1c0 [venus_core]
 sp : ffffffc01376b8d0
 x29: ffffffc01376b8d0 x28: ffffff80cf1b0220
 x27: ffffffc01376bba0 x26: ffffffd8f562b2d8
 x25: ffffff80cf1b0220 x24: 0000000000000005
 x23: ffffffd8f5620d98 x22: ffffff80ca01c800
 x21: ffffff80cf1b0000 x20: ffffff8149490080
 x19: ffffff8174b2c010 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffffd96ee3a0dc
 x15: 0000000000000026 x14: 0000000000000026
 x13: 00000000000055ac x12: 0000000000000001
 x11: deacfffffffffd6c x10: dead000000000100
 x9 : ffffff80ca01cf28 x8 : 0000000000000026
 x7 : 0000000000000000 x6 : ffffff80cdd899c0
 x5 : ffffff80cdd899c0 x4 : 0000000000000008
 x3 : ffffff80ca01cf28 x2 : ffffff80ca01cf28
 x1 : ffffff80d47ffc00 x0 : ffffff80cf1b0000
 Call trace:
  load_scale_v4+0x4c/0x2bc [venus_core]
  session_process_buf+0x18c/0x1c0 [venus_core]
  venus_helper_vb2_buf_queue+0x7c/0xf0 [venus_core]
  __enqueue_in_driver+0xe4/0xfc [videobuf2_common]
  vb2_core_qbuf+0x15c/0x338 [videobuf2_common]
  vb2_qbuf+0x78/0xb8 [videobuf2_v4l2]
  v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem]
  v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem]
  v4l_qbuf+0x48/0x58
  __video_do_ioctl+0x2b0/0x39c
  video_usercopy+0x394/0x710
  video_ioctl2+0x38/0x48
  v4l2_ioctl+0x6c/0x80
  do_video_ioctl+0xb00/0x2874
  v4l2_compat_ioctl32+0x5c/0xcc
  __se_compat_sys_ioctl+0x100/0x2074
  __arm64_compat_sys_ioctl+0x20/0x2c
  el0_svc_common+0xa4/0x154
  el0_svc_compat_handler+0x2c/0x38
  el0_svc_compat+0x8/0x10
 Code: eb0a013f 54000200 aa1f03e8 d10e514b (b940016c)
 ---[ end trace e11304b46552e0b9 ]---

Fixes: c0e284ccfeda ("media: venus: Update clock scaling")

Cc: stable@vger.kernel.org # v5.5+
Signed-off-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit fd1ee315dcd4a0f913a74939eb88f6d9b0bd9250 upstream.

Instead of iterate over previously queued buffers in clock
scaling code do cache the payload in instance context structure
for later use when calculating new clock rate.

This will avoid to use spin locks during buffer list iteration
in clock_scaling.

This fixes following kernel Oops:

 Unable to handle kernel paging request at virtual address deacfffffffffd6c
 Mem abort info:
   ESR = 0x96000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
 Data abort info:
   ISV = 0, ISS = 0x00000004
   CM = 0, WnR = 0
 [deacfffffffffd6c] address between user and kernel address ranges
 Internal error: Oops: 96000004 [#1] PREEMPT SMP
 CPU: 7 PID: 5763 Comm: V4L2DecoderThre Tainted: G S      W         5.4.11 #8
 pstate: 20400009 (nzCv daif +PAN -UAO)
 pc : load_scale_v4+0x4c/0x2bc [venus_core]
 lr : session_process_buf+0x18c/0x1c0 [venus_core]
 sp : ffffffc01376b8d0
 x29: ffffffc01376b8d0 x28: ffffff80cf1b0220
 x27: ffffffc01376bba0 x26: ffffffd8f562b2d8
 x25: ffffff80cf1b0220 x24: 0000000000000005
 x23: ffffffd8f5620d98 x22: ffffff80ca01c800
 x21: ffffff80cf1b0000 x20: ffffff8149490080
 x19: ffffff8174b2c010 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffffd96ee3a0dc
 x15: 0000000000000026 x14: 0000000000000026
 x13: 00000000000055ac x12: 0000000000000001
 x11: deacfffffffffd6c x10: dead000000000100
 x9 : ffffff80ca01cf28 x8 : 0000000000000026
 x7 : 0000000000000000 x6 : ffffff80cdd899c0
 x5 : ffffff80cdd899c0 x4 : 0000000000000008
 x3 : ffffff80ca01cf28 x2 : ffffff80ca01cf28
 x1 : ffffff80d47ffc00 x0 : ffffff80cf1b0000
 Call trace:
  load_scale_v4+0x4c/0x2bc [venus_core]
  session_process_buf+0x18c/0x1c0 [venus_core]
  venus_helper_vb2_buf_queue+0x7c/0xf0 [venus_core]
  __enqueue_in_driver+0xe4/0xfc [videobuf2_common]
  vb2_core_qbuf+0x15c/0x338 [videobuf2_common]
  vb2_qbuf+0x78/0xb8 [videobuf2_v4l2]
  v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem]
  v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem]
  v4l_qbuf+0x48/0x58
  __video_do_ioctl+0x2b0/0x39c
  video_usercopy+0x394/0x710
  video_ioctl2+0x38/0x48
  v4l2_ioctl+0x6c/0x80
  do_video_ioctl+0xb00/0x2874
  v4l2_compat_ioctl32+0x5c/0xcc
  __se_compat_sys_ioctl+0x100/0x2074
  __arm64_compat_sys_ioctl+0x20/0x2c
  el0_svc_common+0xa4/0x154
  el0_svc_compat_handler+0x2c/0x38
  el0_svc_compat+0x8/0x10
 Code: eb0a013f 54000200 aa1f03e8 d10e514b (b940016c)
 ---[ end trace e11304b46552e0b9 ]---

Fixes: c0e284ccfeda ("media: venus: Update clock scaling")

Cc: stable@vger.kernel.org # v5.5+
Signed-off-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: i2c: ov5695: Fix power on and off sequences</title>
<updated>2020-04-17T14:13:22+00:00</updated>
<author>
<name>Dongchun Zhu</name>
<email>dongchun.zhu@mediatek.com</email>
</author>
<published>2020-03-11T10:47:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b7faadf5b351cc3d739da54060f40de85a7140c9'/>
<id>b7faadf5b351cc3d739da54060f40de85a7140c9</id>
<content type='text'>
[ Upstream commit f1a64f56663e9d03e509439016dcbddd0166b2da ]

From the measured hardware signal, OV5695 reset pin goes high for a
short period of time during boot-up. From the sensor specification, the
reset pin is active low and the DT binding defines the pin as active
low, which means that the values set by the driver are inverted and thus
the value requested in probe ends up high.

Fix it by changing probe to request the reset GPIO initialized to high,
which makes the initial state of the physical signal low.

In addition, DOVDD rising must occur before DVDD rising from spec., but
regulator_bulk_enable() API enables all the regulators asynchronously.
Use an explicit loops of regulator_enable() instead.

For power off sequence, it is required that DVDD falls first. Given the
bulk API does not give any guarantee about the order of regulators,
change the driver to use regulator_disable() instead.

The sensor also requires a delay between reset high and first I2C
transaction, which was assumed to be 8192 XVCLK cycles, but 1ms is
recommended by the vendor. Fix this as well.

Signed-off-by: Dongchun Zhu &lt;dongchun.zhu@mediatek.com&gt;
Signed-off-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Signed-off-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f1a64f56663e9d03e509439016dcbddd0166b2da ]

From the measured hardware signal, OV5695 reset pin goes high for a
short period of time during boot-up. From the sensor specification, the
reset pin is active low and the DT binding defines the pin as active
low, which means that the values set by the driver are inverted and thus
the value requested in probe ends up high.

Fix it by changing probe to request the reset GPIO initialized to high,
which makes the initial state of the physical signal low.

In addition, DOVDD rising must occur before DVDD rising from spec., but
regulator_bulk_enable() API enables all the regulators asynchronously.
Use an explicit loops of regulator_enable() instead.

For power off sequence, it is required that DVDD falls first. Given the
bulk API does not give any guarantee about the order of regulators,
change the driver to use regulator_disable() instead.

The sensor also requires a delay between reset high and first I2C
transaction, which was assumed to be 8192 XVCLK cycles, but 1ms is
recommended by the vendor. Fix this as well.

Signed-off-by: Dongchun Zhu &lt;dongchun.zhu@mediatek.com&gt;
Signed-off-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Signed-off-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>media: mtk-vpu: avoid unaligned access to DTCM buffer.</title>
<updated>2020-04-17T14:13:22+00:00</updated>
<author>
<name>Hsin-Yi Wang</name>
<email>hsinyi@chromium.org</email>
</author>
<published>2020-03-04T02:58:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ff930e534339b80fb8d096f96b0c69f2f2ec8192'/>
<id>ff930e534339b80fb8d096f96b0c69f2f2ec8192</id>
<content type='text'>
[ Upstream commit e6599adfad30c340d06574e49a86afa7015c5c60 ]

Previously, vpu-&gt;recv_buf and send_buf are forced cast from
void __iomem *tcm. vpu-&gt;recv_buf-&gt;share_buf is passed to
vpu_ipi_desc.handler(). It's not able to do unaligned access. Otherwise
kernel would crash due to unable to handle kernel paging request.

struct vpu_run {
	u32 signaled;
	char fw_ver[VPU_FW_VER_LEN];
	unsigned int	dec_capability;
	unsigned int	enc_capability;
	wait_queue_head_t wq;
};

fw_ver starts at 4 byte boundary. If system enables
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, strscpy() will do
read_word_at_a_time(), which tries to read 8-byte: *(unsigned long *)addr

vpu_init_ipi_handler() calls strscpy(), which would lead to crash.

vpu_init_ipi_handler() and several other handlers (eg.
vpu_dec_ipi_handler) only do read access to this data, so they can be
const, and we can use memcpy_fromio() to copy the buf to another non iomem
buffer then pass to handler.

Fixes: 85709cbf1524 ("media: replace strncpy() by strscpy()")
Signed-off-by: Hsin-Yi Wang &lt;hsinyi@chromium.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e6599adfad30c340d06574e49a86afa7015c5c60 ]

Previously, vpu-&gt;recv_buf and send_buf are forced cast from
void __iomem *tcm. vpu-&gt;recv_buf-&gt;share_buf is passed to
vpu_ipi_desc.handler(). It's not able to do unaligned access. Otherwise
kernel would crash due to unable to handle kernel paging request.

struct vpu_run {
	u32 signaled;
	char fw_ver[VPU_FW_VER_LEN];
	unsigned int	dec_capability;
	unsigned int	enc_capability;
	wait_queue_head_t wq;
};

fw_ver starts at 4 byte boundary. If system enables
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, strscpy() will do
read_word_at_a_time(), which tries to read 8-byte: *(unsigned long *)addr

vpu_init_ipi_handler() calls strscpy(), which would lead to crash.

vpu_init_ipi_handler() and several other handlers (eg.
vpu_dec_ipi_handler) only do read access to this data, so they can be
const, and we can use memcpy_fromio() to copy the buf to another non iomem
buffer then pass to handler.

Fixes: 85709cbf1524 ("media: replace strncpy() by strscpy()")
Signed-off-by: Hsin-Yi Wang &lt;hsinyi@chromium.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>media: i2c: video-i2c: fix build errors due to 'imply hwmon'</title>
<updated>2020-04-17T14:13:21+00:00</updated>
<author>
<name>Matt Ranostay</name>
<email>matt.ranostay@konsulko.com</email>
</author>
<published>2020-03-24T01:07:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b73e58ebb8992167d92452d21ef4322789e973bf'/>
<id>b73e58ebb8992167d92452d21ef4322789e973bf</id>
<content type='text'>
[ Upstream commit 64d4fc9926f09861a35d8f0f7d81f056e6d5af7b ]

Fix build fault when CONFIG_HWMON is a module, and CONFIG_VIDEO_I2C
as builtin. This is due to 'imply hwmon' in the respective Kconfig.

Issue build log:

ld: drivers/media/i2c/video-i2c.o: in function `amg88xx_hwmon_init':
video-i2c.c:(.text+0x2e1): undefined reference to `devm_hwmon_device_register_with_info

Cc: rdunlap@infradead.org
Fixes: acbea6798955 (media: video-i2c: add hwmon support for amg88xx)
Signed-off-by: Matt Ranostay &lt;matt.ranostay@konsulko.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 64d4fc9926f09861a35d8f0f7d81f056e6d5af7b ]

Fix build fault when CONFIG_HWMON is a module, and CONFIG_VIDEO_I2C
as builtin. This is due to 'imply hwmon' in the respective Kconfig.

Issue build log:

ld: drivers/media/i2c/video-i2c.o: in function `amg88xx_hwmon_init':
video-i2c.c:(.text+0x2e1): undefined reference to `devm_hwmon_device_register_with_info

Cc: rdunlap@infradead.org
Fixes: acbea6798955 (media: video-i2c: add hwmon support for amg88xx)
Signed-off-by: Matt Ranostay &lt;matt.ranostay@konsulko.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>media: venus: hfi_parser: Ignore HEVC encoding for V1</title>
<updated>2020-04-17T14:13:17+00:00</updated>
<author>
<name>Stephan Gerhold</name>
<email>stephan@gerhold.net</email>
</author>
<published>2019-12-09T19:16:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9c55d757c96ca73f2c0723ae966d9240278e429a'/>
<id>9c55d757c96ca73f2c0723ae966d9240278e429a</id>
<content type='text'>
[ Upstream commit c50cc6dc6c48300af63a6fbc71b647053c15fc80 ]

Some older MSM8916 Venus firmware versions also seem to indicate
support for encoding HEVC, even though they really can't.
This will lead to errors later because hfi_session_init() fails
in this case.

HEVC is already ignored for "dec_codecs", so add the same for
"enc_codecs" to make these old firmware versions work correctly.

Signed-off-by: Stephan Gerhold &lt;stephan@gerhold.net&gt;
Signed-off-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit c50cc6dc6c48300af63a6fbc71b647053c15fc80 ]

Some older MSM8916 Venus firmware versions also seem to indicate
support for encoding HEVC, even though they really can't.
This will lead to errors later because hfi_session_init() fails
in this case.

HEVC is already ignored for "dec_codecs", so add the same for
"enc_codecs" to make these old firmware versions work correctly.

Signed-off-by: Stephan Gerhold &lt;stephan@gerhold.net&gt;
Signed-off-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>media: vimc: streamer: fix memory leak in vimc subdevs if kthread_run fails</title>
<updated>2020-04-17T14:13:16+00:00</updated>
<author>
<name>Dafna Hirschfeld</name>
<email>dafna.hirschfeld@collabora.com</email>
</author>
<published>2020-01-13T18:59:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f533a90de15afd2b65531c7701e10c240b0c2ad8'/>
<id>f533a90de15afd2b65531c7701e10c240b0c2ad8</id>
<content type='text'>
[ Upstream commit ceeb2e6166dddf3c9757abbbf84032027e2fa2d2 ]

In case kthread_run fails, the vimc subdevices
should be notified that streaming stopped so they can
release the memory for the streaming. Also, kthread should be
set to NULL.

Signed-off-by: Dafna Hirschfeld &lt;dafna.hirschfeld@collabora.com&gt;
Acked-by: Helen Koike &lt;helen.koike@collabora.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ceeb2e6166dddf3c9757abbbf84032027e2fa2d2 ]

In case kthread_run fails, the vimc subdevices
should be notified that streaming stopped so they can
release the memory for the streaming. Also, kthread should be
set to NULL.

Signed-off-by: Dafna Hirschfeld &lt;dafna.hirschfeld@collabora.com&gt;
Acked-by: Helen Koike &lt;helen.koike@collabora.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
