<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/media, branch v4.9.87</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>media: m88ds3103: don't call a non-initalized function</title>
<updated>2018-03-11T15:21:29+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@s-opensource.com</email>
</author>
<published>2018-02-10T11:14:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9bcc9ac1cfd280e8795eb6b9fe3120a5682af939'/>
<id>9bcc9ac1cfd280e8795eb6b9fe3120a5682af939</id>
<content type='text'>
commit b9c97c67fd19262c002d94ced2bfb513083e161e upstream.

If m88d3103 chip ID is not recognized, the device is not initialized.

However, it returns from probe without any error, causing this OOPS:

[    7.689289] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    7.689297] pgd = 7b0bd7a7
[    7.689302] [00000000] *pgd=00000000
[    7.689318] Internal error: Oops: 80000005 [#1] SMP ARM
[    7.689322] Modules linked in: dvb_usb_dvbsky(+) m88ds3103 dvb_usb_v2 dvb_core videobuf2_vmalloc videobuf2_memops videobuf2_core crc32_arm_ce videodev media
[    7.689358] CPU: 3 PID: 197 Comm: systemd-udevd Not tainted 4.15.0-mcc+ #23
[    7.689361] Hardware name: BCM2835
[    7.689367] PC is at 0x0
[    7.689382] LR is at m88ds3103_attach+0x194/0x1d0 [m88ds3103]
[    7.689386] pc : [&lt;00000000&gt;]    lr : [&lt;bf0ae1ec&gt;]    psr: 60000013
[    7.689391] sp : ed8e5c20  ip : ed8c1e00  fp : ed8945c0
[    7.689395] r10: ed894000  r9 : ed894378  r8 : eda736c0
[    7.689400] r7 : ed894070  r6 : ed8e5c44  r5 : bf0bb040  r4 : eda77600
[    7.689405] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : eda77600
[    7.689412] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    7.689417] Control: 10c5383d  Table: 2d8e806a  DAC: 00000051
[    7.689423] Process systemd-udevd (pid: 197, stack limit = 0xe9dbfb63)
[    7.689428] Stack: (0xed8e5c20 to 0xed8e6000)
[    7.689439] 5c20: ed853a80 eda73640 ed894000 ed8942c0 ed853a80 bf0b9e98 ed894070 bf0b9f10
[    7.689449] 5c40: 00000000 00000000 bf08c17c c08dfc50 00000000 00000000 00000000 00000000
[    7.689459] 5c60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.689468] 5c80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.689479] 5ca0: 00000000 00000000 ed8945c0 ed8942c0 ed894000 ed894830 bf0b9e98 00000000
[    7.689490] 5cc0: ed894378 bf0a3cb4 bf0bc3b0 0000533b ed920540 00000000 00000034 bf0a6434
[    7.689500] 5ce0: ee952070 ed826600 bf0a7038 bf0a2dd8 00000001 bf0a6768 bf0a2f90 ed8943c0
[    7.689511] 5d00: 00000000 c08eca68 ed826620 ed826620 00000000 ee952070 bf0bc034 ee952000
[    7.689521] 5d20: ed826600 bf0bb080 ffffffed c0aa9e9c c0aa9dac ed826620 c16edf6c c168c2c8
[    7.689531] 5d40: c16edf70 00000000 bf0bc034 0000000d 00000000 c08e268c bf0bb080 ed826600
[    7.689541] 5d60: bf0bc034 ed826654 ed826620 bf0bc034 c164c8bc 00000000 00000001 00000000
[    7.689553] 5d80: 00000028 c08e2948 00000000 bf0bc034 c08e2848 c08e0778 ee9f0a58 ed88bab4
[    7.689563] 5da0: bf0bc034 ed90ba80 c168c1f0 c08e1934 bf0bb3bc c17045ac bf0bc034 c164c8bc
[    7.689574] 5dc0: bf0bc034 bf0bb3bc ed91f564 c08e34ec bf0bc000 c164c8bc bf0bc034 c0aa8dc4
[    7.689584] 5de0: ffffe000 00000000 bf0bf000 ed91f600 ed91f564 c03021e4 00000001 00000000
[    7.689595] 5e00: c166e040 8040003f ed853a80 bf0bc448 00000000 c1678174 ed853a80 f0f22000
[    7.689605] 5e20: f0f21fff 8040003f 014000c0 ed91e700 ed91e700 c16d8e68 00000001 ed91e6c0
[    7.689615] 5e40: bf0bc400 00000001 bf0bc400 ed91f564 00000001 00000000 00000028 c03c9a24
[    7.689625] 5e60: 00000001 c03c8c94 ed8e5f50 ed8e5f50 00000001 bf0bc400 ed91f540 c03c8cb0
[    7.689637] 5e80: bf0bc40c 00007fff bf0bc400 c03c60b0 00000000 bf0bc448 00000028 c0e09684
[    7.689647] 5ea0: 00000002 bf0bc530 c1234bf8 bf0bc5dc bf0bc514 c10ebbe8 ffffe000 bf000000
[    7.689657] 5ec0: 00011538 00000000 ed8e5f48 00000000 00000000 00000000 00000000 00000000
[    7.689666] 5ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.689676] 5f00: 00000000 00000000 7fffffff 00000000 00000013 b6e55a18 0000017b c0309104
[    7.689686] 5f20: ed8e4000 00000000 00510af0 c03c9430 7fffffff 00000000 00000003 00000000
[    7.689697] 5f40: 00000000 f0f0f000 00011538 00000000 f0f107b0 f0f0f000 00011538 f0f1fdb8
[    7.689707] 5f60: f0f1fbe8 f0f1b974 00004000 000041e0 bf0bc3d0 00000001 00000000 000024c4
[    7.689717] 5f80: 0000002d 0000002e 00000019 00000000 00000010 00000000 16894000 00000000
[    7.689727] 5fa0: 00000000 c0308f20 16894000 00000000 00000013 b6e55a18 00000000 b6e5652c
[    7.689737] 5fc0: 16894000 00000000 00000000 0000017b 00020000 00508110 00000000 00510af0
[    7.689748] 5fe0: bef68948 bef68938 b6e4d3d0 b6d32590 60000010 00000013 00000000 00000000
[    7.689790] [&lt;bf0ae1ec&gt;] (m88ds3103_attach [m88ds3103]) from [&lt;bf0b9f10&gt;] (dvbsky_s960c_attach+0x78/0x280 [dvb_usb_dvbsky])
[    7.689821] [&lt;bf0b9f10&gt;] (dvbsky_s960c_attach [dvb_usb_dvbsky]) from [&lt;bf0a3cb4&gt;] (dvb_usbv2_probe+0xa3c/0x1024 [dvb_usb_v2])
[    7.689849] [&lt;bf0a3cb4&gt;] (dvb_usbv2_probe [dvb_usb_v2]) from [&lt;c0aa9e9c&gt;] (usb_probe_interface+0xf0/0x2a8)
[    7.689869] [&lt;c0aa9e9c&gt;] (usb_probe_interface) from [&lt;c08e268c&gt;] (driver_probe_device+0x2f8/0x4b4)
[    7.689881] [&lt;c08e268c&gt;] (driver_probe_device) from [&lt;c08e2948&gt;] (__driver_attach+0x100/0x11c)
[    7.689895] [&lt;c08e2948&gt;] (__driver_attach) from [&lt;c08e0778&gt;] (bus_for_each_dev+0x4c/0x9c)
[    7.689909] [&lt;c08e0778&gt;] (bus_for_each_dev) from [&lt;c08e1934&gt;] (bus_add_driver+0x1c0/0x264)
[    7.689919] [&lt;c08e1934&gt;] (bus_add_driver) from [&lt;c08e34ec&gt;] (driver_register+0x78/0xf4)
[    7.689931] [&lt;c08e34ec&gt;] (driver_register) from [&lt;c0aa8dc4&gt;] (usb_register_driver+0x70/0x134)
[    7.689946] [&lt;c0aa8dc4&gt;] (usb_register_driver) from [&lt;c03021e4&gt;] (do_one_initcall+0x44/0x168)
[    7.689963] [&lt;c03021e4&gt;] (do_one_initcall) from [&lt;c03c9a24&gt;] (do_init_module+0x64/0x1f4)
[    7.689979] [&lt;c03c9a24&gt;] (do_init_module) from [&lt;c03c8cb0&gt;] (load_module+0x20a0/0x25c8)
[    7.689993] [&lt;c03c8cb0&gt;] (load_module) from [&lt;c03c9430&gt;] (SyS_finit_module+0xb4/0xec)
[    7.690007] [&lt;c03c9430&gt;] (SyS_finit_module) from [&lt;c0308f20&gt;] (ret_fast_syscall+0x0/0x54)
[    7.690018] Code: bad PC value

This may happen on normal circumstances, if, for some reason, the demod
hangs and start returning an invalid chip ID:

[   10.394395] m88ds3103 3-0068: Unknown device. Chip_id=00

So, change the logic to cause probe to fail with -ENODEV, preventing
the OOPS.

Detected while testing DVB MMAP patches on Raspberry Pi 3 with
DVBSky S960CI.

Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&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 b9c97c67fd19262c002d94ced2bfb513083e161e upstream.

If m88d3103 chip ID is not recognized, the device is not initialized.

However, it returns from probe without any error, causing this OOPS:

[    7.689289] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    7.689297] pgd = 7b0bd7a7
[    7.689302] [00000000] *pgd=00000000
[    7.689318] Internal error: Oops: 80000005 [#1] SMP ARM
[    7.689322] Modules linked in: dvb_usb_dvbsky(+) m88ds3103 dvb_usb_v2 dvb_core videobuf2_vmalloc videobuf2_memops videobuf2_core crc32_arm_ce videodev media
[    7.689358] CPU: 3 PID: 197 Comm: systemd-udevd Not tainted 4.15.0-mcc+ #23
[    7.689361] Hardware name: BCM2835
[    7.689367] PC is at 0x0
[    7.689382] LR is at m88ds3103_attach+0x194/0x1d0 [m88ds3103]
[    7.689386] pc : [&lt;00000000&gt;]    lr : [&lt;bf0ae1ec&gt;]    psr: 60000013
[    7.689391] sp : ed8e5c20  ip : ed8c1e00  fp : ed8945c0
[    7.689395] r10: ed894000  r9 : ed894378  r8 : eda736c0
[    7.689400] r7 : ed894070  r6 : ed8e5c44  r5 : bf0bb040  r4 : eda77600
[    7.689405] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : eda77600
[    7.689412] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    7.689417] Control: 10c5383d  Table: 2d8e806a  DAC: 00000051
[    7.689423] Process systemd-udevd (pid: 197, stack limit = 0xe9dbfb63)
[    7.689428] Stack: (0xed8e5c20 to 0xed8e6000)
[    7.689439] 5c20: ed853a80 eda73640 ed894000 ed8942c0 ed853a80 bf0b9e98 ed894070 bf0b9f10
[    7.689449] 5c40: 00000000 00000000 bf08c17c c08dfc50 00000000 00000000 00000000 00000000
[    7.689459] 5c60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.689468] 5c80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.689479] 5ca0: 00000000 00000000 ed8945c0 ed8942c0 ed894000 ed894830 bf0b9e98 00000000
[    7.689490] 5cc0: ed894378 bf0a3cb4 bf0bc3b0 0000533b ed920540 00000000 00000034 bf0a6434
[    7.689500] 5ce0: ee952070 ed826600 bf0a7038 bf0a2dd8 00000001 bf0a6768 bf0a2f90 ed8943c0
[    7.689511] 5d00: 00000000 c08eca68 ed826620 ed826620 00000000 ee952070 bf0bc034 ee952000
[    7.689521] 5d20: ed826600 bf0bb080 ffffffed c0aa9e9c c0aa9dac ed826620 c16edf6c c168c2c8
[    7.689531] 5d40: c16edf70 00000000 bf0bc034 0000000d 00000000 c08e268c bf0bb080 ed826600
[    7.689541] 5d60: bf0bc034 ed826654 ed826620 bf0bc034 c164c8bc 00000000 00000001 00000000
[    7.689553] 5d80: 00000028 c08e2948 00000000 bf0bc034 c08e2848 c08e0778 ee9f0a58 ed88bab4
[    7.689563] 5da0: bf0bc034 ed90ba80 c168c1f0 c08e1934 bf0bb3bc c17045ac bf0bc034 c164c8bc
[    7.689574] 5dc0: bf0bc034 bf0bb3bc ed91f564 c08e34ec bf0bc000 c164c8bc bf0bc034 c0aa8dc4
[    7.689584] 5de0: ffffe000 00000000 bf0bf000 ed91f600 ed91f564 c03021e4 00000001 00000000
[    7.689595] 5e00: c166e040 8040003f ed853a80 bf0bc448 00000000 c1678174 ed853a80 f0f22000
[    7.689605] 5e20: f0f21fff 8040003f 014000c0 ed91e700 ed91e700 c16d8e68 00000001 ed91e6c0
[    7.689615] 5e40: bf0bc400 00000001 bf0bc400 ed91f564 00000001 00000000 00000028 c03c9a24
[    7.689625] 5e60: 00000001 c03c8c94 ed8e5f50 ed8e5f50 00000001 bf0bc400 ed91f540 c03c8cb0
[    7.689637] 5e80: bf0bc40c 00007fff bf0bc400 c03c60b0 00000000 bf0bc448 00000028 c0e09684
[    7.689647] 5ea0: 00000002 bf0bc530 c1234bf8 bf0bc5dc bf0bc514 c10ebbe8 ffffe000 bf000000
[    7.689657] 5ec0: 00011538 00000000 ed8e5f48 00000000 00000000 00000000 00000000 00000000
[    7.689666] 5ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.689676] 5f00: 00000000 00000000 7fffffff 00000000 00000013 b6e55a18 0000017b c0309104
[    7.689686] 5f20: ed8e4000 00000000 00510af0 c03c9430 7fffffff 00000000 00000003 00000000
[    7.689697] 5f40: 00000000 f0f0f000 00011538 00000000 f0f107b0 f0f0f000 00011538 f0f1fdb8
[    7.689707] 5f60: f0f1fbe8 f0f1b974 00004000 000041e0 bf0bc3d0 00000001 00000000 000024c4
[    7.689717] 5f80: 0000002d 0000002e 00000019 00000000 00000010 00000000 16894000 00000000
[    7.689727] 5fa0: 00000000 c0308f20 16894000 00000000 00000013 b6e55a18 00000000 b6e5652c
[    7.689737] 5fc0: 16894000 00000000 00000000 0000017b 00020000 00508110 00000000 00510af0
[    7.689748] 5fe0: bef68948 bef68938 b6e4d3d0 b6d32590 60000010 00000013 00000000 00000000
[    7.689790] [&lt;bf0ae1ec&gt;] (m88ds3103_attach [m88ds3103]) from [&lt;bf0b9f10&gt;] (dvbsky_s960c_attach+0x78/0x280 [dvb_usb_dvbsky])
[    7.689821] [&lt;bf0b9f10&gt;] (dvbsky_s960c_attach [dvb_usb_dvbsky]) from [&lt;bf0a3cb4&gt;] (dvb_usbv2_probe+0xa3c/0x1024 [dvb_usb_v2])
[    7.689849] [&lt;bf0a3cb4&gt;] (dvb_usbv2_probe [dvb_usb_v2]) from [&lt;c0aa9e9c&gt;] (usb_probe_interface+0xf0/0x2a8)
[    7.689869] [&lt;c0aa9e9c&gt;] (usb_probe_interface) from [&lt;c08e268c&gt;] (driver_probe_device+0x2f8/0x4b4)
[    7.689881] [&lt;c08e268c&gt;] (driver_probe_device) from [&lt;c08e2948&gt;] (__driver_attach+0x100/0x11c)
[    7.689895] [&lt;c08e2948&gt;] (__driver_attach) from [&lt;c08e0778&gt;] (bus_for_each_dev+0x4c/0x9c)
[    7.689909] [&lt;c08e0778&gt;] (bus_for_each_dev) from [&lt;c08e1934&gt;] (bus_add_driver+0x1c0/0x264)
[    7.689919] [&lt;c08e1934&gt;] (bus_add_driver) from [&lt;c08e34ec&gt;] (driver_register+0x78/0xf4)
[    7.689931] [&lt;c08e34ec&gt;] (driver_register) from [&lt;c0aa8dc4&gt;] (usb_register_driver+0x70/0x134)
[    7.689946] [&lt;c0aa8dc4&gt;] (usb_register_driver) from [&lt;c03021e4&gt;] (do_one_initcall+0x44/0x168)
[    7.689963] [&lt;c03021e4&gt;] (do_one_initcall) from [&lt;c03c9a24&gt;] (do_init_module+0x64/0x1f4)
[    7.689979] [&lt;c03c9a24&gt;] (do_init_module) from [&lt;c03c8cb0&gt;] (load_module+0x20a0/0x25c8)
[    7.689993] [&lt;c03c8cb0&gt;] (load_module) from [&lt;c03c9430&gt;] (SyS_finit_module+0xb4/0xec)
[    7.690007] [&lt;c03c9430&gt;] (SyS_finit_module) from [&lt;c0308f20&gt;] (ret_fast_syscall+0x0/0x54)
[    7.690018] Code: bad PC value

This may happen on normal circumstances, if, for some reason, the demod
hangs and start returning an invalid chip ID:

[   10.394395] m88ds3103 3-0068: Unknown device. Chip_id=00

So, change the logic to cause probe to fail with -ENODEV, preventing
the OOPS.

Detected while testing DVB MMAP patches on Raspberry Pi 3 with
DVBSky S960CI.

Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>v4l2: disable filesystem-dax mapping support</title>
<updated>2018-02-28T09:18:33+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2018-02-23T22:05:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=53dfce305929bc3c7f4018b7b18027b74284802c'/>
<id>53dfce305929bc3c7f4018b7b18027b74284802c</id>
<content type='text'>
commit b70131de648c2b997d22f4653934438013f407a1 upstream.

V4L2 memory registrations are incompatible with filesystem-dax that
needs the ability to revoke dma access to a mapping at will, or
otherwise allow the kernel to wait for completion of DMA.  The
filesystem-dax implementation breaks the traditional solution of
truncate of active file backed mappings since there is no page-cache
page we can orphan to sustain ongoing DMA.

If v4l2 wants to support long lived DMA mappings it needs to arrange to
hold a file lease or use some other mechanism so that the kernel can
coordinate revoking DMA access when the filesystem needs to truncate
mappings.

Link: http://lkml.kernel.org/r/151068940499.7446.12846708245365671207.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Reported-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Cc: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Doug Ledford &lt;dledford@redhat.com&gt;
Cc: Hal Rosenstock &lt;hal.rosenstock@gmail.com&gt;
Cc: Inki Dae &lt;inki.dae@samsung.com&gt;
Cc: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Cc: Jeff Moyer &lt;jmoyer@redhat.com&gt;
Cc: Joonyoung Shim &lt;jy0922.shim@samsung.com&gt;
Cc: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
Cc: Mel Gorman &lt;mgorman@suse.de&gt;
Cc: Ross Zwisler &lt;ross.zwisler@linux.intel.com&gt;
Cc: Sean Hefty &lt;sean.hefty@intel.com&gt;
Cc: Seung-Woo Kim &lt;sw0312.kim@samsung.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.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 b70131de648c2b997d22f4653934438013f407a1 upstream.

V4L2 memory registrations are incompatible with filesystem-dax that
needs the ability to revoke dma access to a mapping at will, or
otherwise allow the kernel to wait for completion of DMA.  The
filesystem-dax implementation breaks the traditional solution of
truncate of active file backed mappings since there is no page-cache
page we can orphan to sustain ongoing DMA.

If v4l2 wants to support long lived DMA mappings it needs to arrange to
hold a file lease or use some other mechanism so that the kernel can
coordinate revoking DMA access when the filesystem needs to truncate
mappings.

Link: http://lkml.kernel.org/r/151068940499.7446.12846708245365671207.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Reported-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Cc: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Doug Ledford &lt;dledford@redhat.com&gt;
Cc: Hal Rosenstock &lt;hal.rosenstock@gmail.com&gt;
Cc: Inki Dae &lt;inki.dae@samsung.com&gt;
Cc: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Cc: Jeff Moyer &lt;jmoyer@redhat.com&gt;
Cc: Joonyoung Shim &lt;jy0922.shim@samsung.com&gt;
Cc: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
Cc: Mel Gorman &lt;mgorman@suse.de&gt;
Cc: Ross Zwisler &lt;ross.zwisler@linux.intel.com&gt;
Cc: Sean Hefty &lt;sean.hefty@intel.com&gt;
Cc: Seung-Woo Kim &lt;sw0312.kim@samsung.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tw5864: use dev_warn instead of WARN to shut up warning</title>
<updated>2018-02-25T10:05:54+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-02-28T21:14:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7cc1178e8ccf9a0816ebf8f82ec4a778d4ca68ac'/>
<id>7cc1178e8ccf9a0816ebf8f82ec4a778d4ca68ac</id>
<content type='text'>
commit 27430d19a91615245babaa9b216d0807636903a0 upstream.

tw5864_frameinterval_get() only initializes its output when it successfully
identifies the video standard in tw5864_input. We get a warning here because
gcc can't always track the state if initialized warnings across a WARN()
macro, and thinks it might get used incorrectly in tw5864_s_parm:

media/pci/tw5864/tw5864-video.c: In function 'tw5864_s_parm':
media/pci/tw5864/tw5864-video.c:816:38: error: 'time_base.numerator' may be used uninitialized in this function [-Werror=maybe-uninitialized]
media/pci/tw5864/tw5864-video.c:819:31: error: 'time_base.denominator' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Using dev_warn() instead of WARN() avoids the __branch_check__() in
unlikely and lets the compiler see that the initialization is correct.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Andrey Utkin &lt;andrey.utkin@corp.bluecherry.net&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&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 27430d19a91615245babaa9b216d0807636903a0 upstream.

tw5864_frameinterval_get() only initializes its output when it successfully
identifies the video standard in tw5864_input. We get a warning here because
gcc can't always track the state if initialized warnings across a WARN()
macro, and thinks it might get used incorrectly in tw5864_s_parm:

media/pci/tw5864/tw5864-video.c: In function 'tw5864_s_parm':
media/pci/tw5864/tw5864-video.c:816:38: error: 'time_base.numerator' may be used uninitialized in this function [-Werror=maybe-uninitialized]
media/pci/tw5864/tw5864-video.c:819:31: error: 'time_base.denominator' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Using dev_warn() instead of WARN() avoids the __branch_check__() in
unlikely and lets the compiler see that the initialization is correct.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Andrey Utkin &lt;andrey.utkin@corp.bluecherry.net&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>em28xx: only use mt9v011 if camera support is enabled</title>
<updated>2018-02-25T10:05:54+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2016-01-26T14:09:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=507baad9ffb8fc01985337a964e3c6530e9ad5ab'/>
<id>507baad9ffb8fc01985337a964e3c6530e9ad5ab</id>
<content type='text'>
commit 190b23b4eb997767afad186bd8c96badceabf39e upstream.

In randconfig builds that select VIDEO_EM28XX_V4L2 and
MEDIA_SUBDRV_AUTOSELECT, but not MEDIA_CAMERA_SUPPORT, we get
a Kconfig warning:

 warning: (VIDEO_EM28XX_V4L2) selects VIDEO_MT9V011 which has unmet direct dependencies (MEDIA_SUPPORT &amp;&amp; I2C &amp;&amp; VIDEO_V4L2 &amp;&amp; MEDIA_CAMERA_SUPPORT)

This avoids the warning by making that 'select' conditional on
MEDIA_CAMERA_SUPPORT. Alternatively we could mark EM28XX as
'depends on MEDIA_CAMERA_SUPPORT', but it does not seem to
have any real dependency on that itself.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&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 190b23b4eb997767afad186bd8c96badceabf39e upstream.

In randconfig builds that select VIDEO_EM28XX_V4L2 and
MEDIA_SUBDRV_AUTOSELECT, but not MEDIA_CAMERA_SUPPORT, we get
a Kconfig warning:

 warning: (VIDEO_EM28XX_V4L2) selects VIDEO_MT9V011 which has unmet direct dependencies (MEDIA_SUPPORT &amp;&amp; I2C &amp;&amp; VIDEO_V4L2 &amp;&amp; MEDIA_CAMERA_SUPPORT)

This avoids the warning by making that 'select' conditional on
MEDIA_CAMERA_SUPPORT. Alternatively we could mark EM28XX as
'depends on MEDIA_CAMERA_SUPPORT', but it does not seem to
have any real dependency on that itself.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>go7007: add MEDIA_CAMERA_SUPPORT dependency</title>
<updated>2018-02-25T10:05:54+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2016-01-26T14:10:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=25df0c385c5a856dd24c74cb74295ccb805fe93a'/>
<id>25df0c385c5a856dd24c74cb74295ccb805fe93a</id>
<content type='text'>
commit fa6317eedd6341f2144ed1097706d8c34f18b6e4 upstream.

If MEDIA_SUBDRV_AUTOSELECT and VIDEO_GO7007 are both set, we
automatically select VIDEO_OV7640, but that depends on MEDIA_CAMERA_SUPPORT,
so we get a Kconfig warning if that is disabled:

warning: (VIDEO_GO7007) selects VIDEO_OV7640 which has unmet direct dependencies (MEDIA_SUPPORT &amp;&amp; I2C &amp;&amp; VIDEO_V4L2 &amp;&amp; MEDIA_CAMERA_SUPPORT)

This adds another dependency so we don't accidentally select
it when it is unavailable.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&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 fa6317eedd6341f2144ed1097706d8c34f18b6e4 upstream.

If MEDIA_SUBDRV_AUTOSELECT and VIDEO_GO7007 are both set, we
automatically select VIDEO_OV7640, but that depends on MEDIA_CAMERA_SUPPORT,
so we get a Kconfig warning if that is disabled:

warning: (VIDEO_GO7007) selects VIDEO_OV7640 which has unmet direct dependencies (MEDIA_SUPPORT &amp;&amp; I2C &amp;&amp; VIDEO_V4L2 &amp;&amp; MEDIA_CAMERA_SUPPORT)

This adds another dependency so we don't accidentally select
it when it is unavailable.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tc358743: fix register i2c_rd/wr functions</title>
<updated>2018-02-25T10:05:54+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-02-08T21:14:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e4e204f548a0577781f228f92b5fb879af5e32d5'/>
<id>e4e204f548a0577781f228f92b5fb879af5e32d5</id>
<content type='text'>
commit 3538aa6ecfb2dd727a40f9ebbbf25a0c2afe6226 upstream.

While testing with CONFIG_UBSAN, I got this warning:

drivers/media/i2c/tc358743.c: In function 'tc358743_probe':
drivers/media/i2c/tc358743.c:1930:1: error: the frame size of 2480 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

The problem is that the i2c_rd8/wr8/rd16/... functions in this driver pass
a pointer to a local variable into a common function, and each call to one
of them adds another variable plus redzone to the stack.

I also noticed that the way this is done is broken on big-endian machines,
as we copy the registers in CPU byte order.

To address both those problems, I'm adding two helper functions for reading
a register of up to 32 bits with correct endianess and change all other
functions to use that instead. Just to be sure we don't get the problem
back with changed optimizations in gcc, I'm also marking the new functions
as 'noinline', although my tests with gcc-7 don't require that.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&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 3538aa6ecfb2dd727a40f9ebbbf25a0c2afe6226 upstream.

While testing with CONFIG_UBSAN, I got this warning:

drivers/media/i2c/tc358743.c: In function 'tc358743_probe':
drivers/media/i2c/tc358743.c:1930:1: error: the frame size of 2480 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

The problem is that the i2c_rd8/wr8/rd16/... functions in this driver pass
a pointer to a local variable into a common function, and each call to one
of them adds another variable plus redzone to the stack.

I also noticed that the way this is done is broken on big-endian machines,
as we copy the registers in CPU byte order.

To address both those problems, I'm adding two helper functions for reading
a register of up to 32 bits with correct endianess and change all other
functions to use that instead. Just to be sure we don't get the problem
back with changed optimizations in gcc, I'm also marking the new functions
as 'noinline', although my tests with gcc-7 don't require that.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: s5k6aa: describe some function parameters</title>
<updated>2018-02-25T10:05:46+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@s-opensource.com</email>
</author>
<published>2017-11-29T13:44:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=74e9c5b29b12217e37e3c626110a7d0eb187ccca'/>
<id>74e9c5b29b12217e37e3c626110a7d0eb187ccca</id>
<content type='text'>
[ Upstream commit 070250a1715cee2297de0d9e7e2cea58be999d37 ]

as warned:
  drivers/media/i2c/s5k6aa.c:429: warning: No description found for parameter 's5k6aa'
  drivers/media/i2c/s5k6aa.c:679: warning: No description found for parameter 's5k6aa'
  drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 's5k6aa'
  drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 'preset'
  drivers/media/i2c/s5k6aa.c:787: warning: No description found for parameter 'sd'

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&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>
[ Upstream commit 070250a1715cee2297de0d9e7e2cea58be999d37 ]

as warned:
  drivers/media/i2c/s5k6aa.c:429: warning: No description found for parameter 's5k6aa'
  drivers/media/i2c/s5k6aa.c:679: warning: No description found for parameter 's5k6aa'
  drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 's5k6aa'
  drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 'preset'
  drivers/media/i2c/s5k6aa.c:787: warning: No description found for parameter 'sd'

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>media: r820t: fix r820t_write_reg for KASAN</title>
<updated>2018-02-22T14:43:56+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-11-30T11:08:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=08e4d04569874f79963a40890e790d2b4c33ed30'/>
<id>08e4d04569874f79963a40890e790d2b4c33ed30</id>
<content type='text'>
commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream.

With CONFIG_KASAN, we get an overly long stack frame due to inlining
the register access functions:

drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

This is caused by a gcc bug that has now been fixed in gcc-8.
To work around the problem, we can pass the register data
through a local variable that older gcc versions can optimize
out as well.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&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 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream.

With CONFIG_KASAN, we get an overly long stack frame due to inlining
the register access functions:

drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

This is caused by a gcc bug that has now been fixed in gcc-8.
To work around the problem, we can pass the register data
through a local variable that older gcc versions can optimize
out as well.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: cxusb, dib0700: ignore XC2028_I2C_FLUSH</title>
<updated>2018-02-17T12:21:18+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@osg.samsung.com</email>
</author>
<published>2018-01-24T11:01:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1666d38f4ed6cbf2bacaad21f04d77ca64c4808a'/>
<id>1666d38f4ed6cbf2bacaad21f04d77ca64c4808a</id>
<content type='text'>
commit 9893b905e743ded332575ca04486bd586c0772f7 upstream.

The XC2028_I2C_FLUSH only needs to be implemented on a few
devices. Others can safely ignore it.

That prevents filling the dmesg with lots of messages like:

	dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0

Fixes: 4d37ece757a8 ("[media] tuner/xc2028: Add I2C flush callback")
Reported-by: Enrico Mioso &lt;mrkiko.rs@gmail.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@osg.samsung.com&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 9893b905e743ded332575ca04486bd586c0772f7 upstream.

The XC2028_I2C_FLUSH only needs to be implemented on a few
devices. Others can safely ignore it.

That prevents filling the dmesg with lots of messages like:

	dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0

Fixes: 4d37ece757a8 ("[media] tuner/xc2028: Add I2C flush callback")
Reported-by: Enrico Mioso &lt;mrkiko.rs@gmail.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@osg.samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: ts2020: avoid integer overflows on 32 bit machines</title>
<updated>2018-02-17T12:21:18+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@s-opensource.com</email>
</author>
<published>2018-01-10T12:20:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b2e7c63cad18341525643716bc62e5ac4ee50485'/>
<id>b2e7c63cad18341525643716bc62e5ac4ee50485</id>
<content type='text'>
commit 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 upstream.

Before this patch, when compiled for arm32, the signal strength
were reported as:

Lock   (0x1f) Signal= 4294908.66dBm C/N= 12.79dB

Because of a 32 bit integer overflow. After it, it is properly
reported as:

	Lock   (0x1f) Signal= -58.64dBm C/N= 12.79dB

Fixes: 0f91c9d6bab9 ("[media] TS2020: Calculate tuner gain correctly")
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&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 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 upstream.

Before this patch, when compiled for arm32, the signal strength
were reported as:

Lock   (0x1f) Signal= 4294908.66dBm C/N= 12.79dB

Because of a 32 bit integer overflow. After it, it is properly
reported as:

	Lock   (0x1f) Signal= -58.64dBm C/N= 12.79dB

Fixes: 0f91c9d6bab9 ("[media] TS2020: Calculate tuner gain correctly")
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
