- 29 Nov, 2021 2 commits
-
-
Mauro Carvalho Chehab authored
The gobj_type() function translates the media object type into a name, being useful for debugging purposes. It is currently not used. So, drop it. Signed-off-by:Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
The stb6100_normalise_regs() function is not used with current boards, but the driver says that some devices could need it. Ok, we could simply drop it, but as there's a macro to mark unused functions, use it. This should shut up a clang warning. Signed-off-by:
-
- 22 Nov, 2021 15 commits
-
-
Mauro Carvalho Chehab authored
The macro p_to_snd_cx18_card() is just a variant for container_of(), not actually used inside the code. So, drop it. This address a clang warning. Signed-off-by: -
Mauro Carvalho Chehab authored
The macro p_to_snd_ivtv_card() is just a variant for container_of(), not actually used inside the code. So, drop it. This address a clang warning. Signed-off-by: -
Mauro Carvalho Chehab authored
This function is defined twice, one at cx25821-i2c and the other inside cx25821-core. It turns that only the first is actually used inside the code. This causes a clang warning. Signed-off-by: -
Andrzej Pietrasiewicz authored
The G2 decoder block produces NV12 4x4 tiled format (NV12_4L4). Enable the G2 post-processor block, in order to produce regular NV12. The logic in hantro_postproc.c is leveraged to take care of allocating the extra buffers and configure the post-processor, which is significantly simpler than the one on the G1. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Andrzej Pietrasiewicz authored
The struct is not used outside this file, so it can be static. Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Andrzej Pietrasiewicz authored
VeriSilicon Hantro G2 core supports VP9 codec. [hverkuil: add kerneldoc line for HANTRO_MODE_VP9_DEC] Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by:
-
Andrzej Pietrasiewicz authored
VeriSilicon Hantro G2 core supports other codecs besides hevc. Factor out some common code in preparation for vp9 support. Signed-off-by:
-
Andrzej Pietrasiewicz authored
Add more consistency in the way registers are named. Signed-off-by:
-
Andrzej Pietrasiewicz authored
The Rockchip VDEC supports VP9 profile 0 up to 4096x2304@30fps. Add a backend for this new format. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Adrian Ratiu <adrian.ratiu@collabora.com> Co-developed-by:
-
Andrzej Pietrasiewicz authored
Provide code common to vp9 drivers in one central location. Signed-off-by:
-
Andrzej Pietrasiewicz authored
Add the VP9 stateless decoder controls plus the documentation that goes with it. Signed-off-by:
Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
The G2 core decoder engine produces NV12_4L4 format, which is a simple NV12 4x4 tiled format. The driver currently hides this format by always enabling the post-processor engine, and therefore offering NV12 directly. This is done without using the logic in hantro_postproc.c and therefore makes it difficult to add VP9 cleanly. Since fixing this is not easy, add a small quirk to force NV12 if HEVC was configured, but otherwise declare NV12_4L4 as the pixel format in imx8mq_vpu_g2_variant.dec_fmts. This will be used by the VP9 decoder which will be added soon. Signed-off-by:
-
Ezequiel Garcia authored
Add a 'postprocessed' boolean property to struct hantro_fmt to signal that a format is produced by the post-processor. This will allow to introduce the G2 post-processor in a simple way. Signed-off-by:
-
Ezequiel Garcia authored
Turns out the post-processor block on the G2 core is substantially different from the one on the G1 core. Introduce hantro_postproc_ops with .enable and .disable methods, which will allow to support the G2 post-processor cleanly. Signed-off-by:
-
Ezequiel Garcia authored
When the post-processor hardware block is enabled, the driver allocates an internal queue of buffers for the decoder enginer, and uses the vb2 queue for the post-processor engine. For instance, on a G1 core, the decoder engine produces NV12 buffers and the post-processor engine can produce YUY2 buffers. The decoder engine expects motion vectors to be appended to the NV12 buffers, but this is only required for CODECs that need motion vectors, such as H.264. Fix the post-processor logic accordingly. Signed-off-by:
-
- 19 Nov, 2021 23 commits
-
-
Sudip Mukherjee authored
The pointer 'mem' was initialized to 'fw->data' but immediately after that it was assigned 'fw->data + 10'. Lets remove the extra assignement and initialize the pointer to the address its going to use. Link: https://lore.kernel.org/linux-media/20210416235336.1552102-1-sudipm.mukherjee@gmail.com Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
-
Lukas Middendorf authored
At connection time (or boot) in si2168_probe(), the firmware is not loaded to the device and the device is not fully activated. It is not useful or sensible to do this full initialization on resume in case it has not been previously initialized and is expected to be in this initialized state. Calling si2168_init() and therefore reading the firmware file for the first time during resume leads to problems and should be avoided. It is however safe to read the firmware file once it has already been read outside of a suspend/resume situation. Add a staus flag 'initialized' to store whether si2168_init() has successfully been called. If initialization fails (e.g. due to missing firmware file), the flag is not set. Register a separate si2168_resume callback which only calls si2168_init() once the 'initialized' flag has been set and it is safe to load the firmware at resume. The first call to si2168_init() will now always happen when the device is actually used for the first time and never during resume. This avoids the unsafe firmware file reading and should also speed up resume by skipping unnecessary device initialization. Link: https://lore.kernel.org/linux-media/20210418001204.7453-3-kernel@tuxforce.de [mchehab: fix several Coding Style issues] Cc: Antti Palosaari <crope@iki.fi> Signed-off-by:
Lukas Middendorf <kernel@tuxforce.de> Signed-off-by:
-
Lukas Middendorf authored
The si2168 B40 firmware file name has been changed in or before 2014. During initialization, the new file name is preferred, but the old file name is used as a fallback when request_firmware with the new file name fails. Once reading the old file name has been attempted, only this name will be used on further firmware loading attempts. During resume, firmware reading with the new file name can (and likely will) fail even when it actually exists. So this permanent switch to the fallback firmware name happens even when not desired. Any system using a recent kernel version can be expected to have the firmware under the new name. The major distributions are either using the dvb firmware collection from LibreELEC, which has the new firmware file name, or do not package the firmware file but have documentation pointing towards a manual installation of the firmware file under the new name. If the firmware is available under the old name, it is severely outdated. If the switch to the old file name is performed, further firmware loading will either permanently fail (if it is not available) or an outdated firmware version will be used. Drop support for the fallback firmware file name and fail directly if the firmware is not available under its current name. On following attempts, the firmware read will then be retried with the correct current name instead of the old name. As reasoned above, there should be no negative effects of this change, while simplifying code (the B40 variant will be handled identical compared to the other variants of the si2168) and at the same time fixing possible problems if firmware loading fails on resume. Link: https://lore.kernel.org/linux-media/20210418161544.58858-1-kernel@tuxforce.deSigned-off-by:
-
Mauro Carvalho Chehab authored
Only touch the right bit to enable/disable an adapter channel, without touching the other adapter's one. Tested on Nova-TD. Link: https://lore.kernel.org/linux-media/4214942f248baddec9cfd2b4b2424993ac356a51.1632689033.git.mchehab+huawei@kernel.org Cc: linuxarm@huawei.com, mauro.chehab@huawei.com, Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, Mauro Carvalho Chehab <mchehab@kernel.org>, Michael Kuron <michael.kuron@gmail.com>, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, pb@linuxtv.org Signed-off-by:
-
Mauro Carvalho Chehab authored
Having two different paths to start/stop streaming, depending weather the USB endpoints are 0x82/0x83 or not makes it more prune to errors. Unify the logic. Link: https://lore.kernel.org/linux-media/065a6fff925a42153671fa5202c81882ca12c59c.1632689033.git.mchehab+huawei@kernel.org Cc: linuxarm@huawei.com, mauro.chehab@huawei.com, Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, Mauro Carvalho Chehab <mchehab@kernel.org>, Michael Kuron <michael.kuron@gmail.com>, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, pb@linuxtv.org Signed-off-by:
-
Michael Kuron authored
This fixes a problem where closing the tuner would leave it in a state where it would not tune to any channel when reopened. This problem was discovered as part of https://github.com/hselasky/webcamd/issues/16. Since adap->id is 0 or 1, this bit-shift overflows, which is undefined behavior. The driver still worked in practice as the overflow would in most environments result in 0, which rendered the line a no-op. When running the driver as part of webcamd however, the overflow could lead to 0xff due to optimizations by the compiler, which would, in the end, improperly shut down the tuner. The bug is a regression introduced in the commit referenced below. The present patch causes identical behavior to before that commit for adap->id equal to 0 or 1. The driver does not contain support for dib0700 devices with more adapters, assuming such even exist. Tests have been performed with the Xbox One Digital TV Tuner on amd64. Not all dib0700 devices are expected to be affected by the regression; this code path is only taken by those with incorrect endpoint numbers. Link: https://lore.kernel.org/linux-media/1d2fc36d94ced6f67c7cc21dcc469d5e5bdd8201.1632689033.git.mchehab+huawei@kernel.org Cc: stable@vger.kernel.org Fixes: 7757ddda ("[media] DiB0700: add function to change I2C-speed") Signed-off-by:
Michael Kuron <michael.kuron@gmail.com> Signed-off-by:
-
Scott K Logan authored
This looks like a typo. By manipulating the antenna on a device while monitoring the reported SNR, I was able to see the unexpected jump. After applying this patch, the spike was no longer present. Link: https://lore.kernel.org/linux-media/20211003001805.735092-1-logans@cottsay.netSigned-off-by:
Scott K Logan <logans@cottsay.net> Signed-off-by:
-
Colin Ian King authored
Variable r is being assigned values but its value was never used, being overriden on its first usage. So, drop the initialization. Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/linux-media/20211014151235.62671-1-colin.king@canonical.com Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Colin Ian King authored
GIT_AUTHOR_NAME=Colin King GIT_AUTHOR_EMAIL=colin.king@canonical.com Variable ADCClk_Hz is being initialised with a variable that is never read and then re-assigned immediately afterwards. Clean up the code by removing it and just returning the return value from the call to stv0367cab_get_mclk Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/linux-media/20211014153253.63527-1-colin.king@canonical.com Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Signed-off-by: -
zhaoxiao authored
Fix following coccicheck warning: drivers/media/dvb-frontends/dib9000.c:261:10-11: WARNING opportunity for min() drivers/media/dvb-frontends/dib9000.c:345:10-11: WARNING opportunity for min() Link: https://lore.kernel.org/linux-media/20211117030656.14984-1-zhaoxiao@uniontech.com Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, zhaoxiao <zhaoxiao@uniontech.com> Signed-off-by:
zhaoxiao <zhaoxiao@uniontech.com> Signed-off-by:
-
Lukas Middendorf authored
While dvb_tuner_ops already has dedicated suspend and resume callbacks, dvb_frontend_ops currently does not have them. Add those callbacks and use them for suspend and resume. If they are not set, the old behavior of calling sleep or init is used. This allows dvb_frontend drivers to handle resume differently from init, and suspend differently from sleep. No change is required for drivers not needing this functionality. Link: https://lore.kernel.org/linux-media/20210418001204.7453-2-kernel@tuxforce.de Cc: Lukas Middendorf <kernel@tuxforce.de>, Antti Palosaari <crope@iki.fi>, Mauro Carvalho Chehab <mchehab@kernel.org>, Luis Chamberlain <mcgrof@kernel.org> Signed-off-by:
-
Zheyu Ma authored
A out-of-bounds bug can be triggered by an interrupt, the reason for this bug is the lack of checking of register values. In flexcop_pci_isr, the driver reads value from a register and uses it as a dma address. Finally, this address will be passed to the count parameter of find_next_packet. If this value is larger than the size of dma, the index of buffer will be out-of-bounds. Fix this by adding a check after reading the value of the register. The following KASAN report reveals it: BUG: KASAN: slab-out-of-bounds in find_next_packet drivers/media/dvb-core/dvb_demux.c:528 [inline] BUG: KASAN: slab-out-of-bounds in _dvb_dmx_swfilter drivers/media/dvb-core/dvb_demux.c:572 [inline] BUG: KASAN: slab-out-of-bounds in dvb_dmx_swfilter+0x3fa/0x420 drivers/media/dvb-core/dvb_demux.c:603 Read of size 1 at addr ffff8880608c00a0 by task swapper/2/0 CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 print_address_description+0x78/0x290 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report+0x25b/0x380 mm/kasan/report.c:412 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:430 find_next_packet drivers/media/dvb-core/dvb_demux.c:528 [inline] _dvb_dmx_swfilter drivers/media/dvb-core/dvb_demux.c:572 [inline] dvb_dmx_swfilter+0x3fa/0x420 drivers/media/dvb-core/dvb_demux.c:603 flexcop_pass_dmx_data+0x2e/0x40 drivers/media/common/b2c2/flexcop.c:167 flexcop_pci_isr+0x3d1/0x5d0 drivers/media/pci/b2c2/flexcop-pci.c:212 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 </IRQ> RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 62 2f 8c 48 89 e5 e8 fb 31 e8 f8 8b 05 75 4f 8e 03 85 c0 7e 07 0f 00 2d 8a 61 66 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde44c8 RCX: ffffffff88a11285 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2f6200 RBP: ffff88806b71fcc8 R08: fffffbfff185ec40 R09: fffffbfff185ec40 R10: 0000000000000001 R11: fffffbfff185ec40 R12: 0000000000000002 R13: ffffffff8be9d6e0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 Allocated by task 1: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x11/0x20 mm/kasan/kasan.c:490 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2741 [inline] slab_alloc mm/slub.c:2749 [inline] kmem_cache_alloc+0xeb/0x280 mm/slub.c:2754 kmem_cache_zalloc include/linux/slab.h:699 [inline] __kernfs_new_node+0xe2/0x6f0 fs/kernfs/dir.c:633 kernfs_new_node+0x9a/0x120 fs/kernfs/dir.c:693 __kernfs_create_file+0x5f/0x340 fs/kernfs/file.c:992 sysfs_add_file_mode_ns+0x22a/0x4e0 fs/sysfs/file.c:306 create_files fs/sysfs/group.c:63 [inline] internal_create_group+0x34e/0xc30 fs/sysfs/group.c:147 sysfs_create_group fs/sysfs/group.c:173 [inline] sysfs_create_groups+0x9c/0x140 fs/sysfs/group.c:200 driver_add_groups+0x3e/0x50 drivers/base/driver.c:129 bus_add_driver+0x3a5/0x790 drivers/base/bus.c:684 driver_register+0x1cd/0x410 drivers/base/driver.c:170 __pci_register_driver+0x197/0x200 drivers/pci/pci-driver.c:1411 cx88_audio_pci_driver_init+0x23/0x25 drivers/media/pci/cx88/cx88-alsa.c: 1017 do_one_initcall+0xe0/0x610 init/main.c:884 do_initcall_level init/main.c:952 [inline] do_initcalls init/main.c:960 [inline] do_basic_setup init/main.c:978 [inline] kernel_init_freeable+0x4d0/0x592 init/main.c:1145 kernel_init+0x18/0x190 init/main.c:1062 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff8880608c0000 which belongs to the cache kernfs_node_cache of size 160 The buggy address is located 0 bytes to the right of 160-byte region [ffff8880608c0000, ffff8880608c00a0) The buggy address belongs to the page: page:ffffea0001823000 count:1 mapcount:0 mapping:ffff88806bed1e00 index:0x0 compound_mapcount: 0 flags: 0x100000000008100(slab|head) raw: 0100000000008100 dead000000000100 dead000000000200 ffff88806bed1e00 raw: 0000000000000000 0000000000240024 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880608bff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880608c0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8880608c0080: 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00 00 ^ ffff8880608c0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880608c0180: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 ================================================================== Link: https://lore.kernel.org/linux-media/1620723603-30912-1-git-send-email-zheyuma97@gmail.comReported-by:Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
-
Cai Huoqing authored
use SPDX-License-Identifier instead of a verbose license text and remove verbose license text. Link: https://lore.kernel.org/linux-media/20210916020018.8550-1-caihuoqing@baidu.comSigned-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
Wang Hai authored
I got a use-after-free report: dvbdev: dvb_register_device: failed to create device dvb1.dvr0 (-12) ... ================================================================== BUG: KASAN: use-after-free in dvb_dmxdev_release+0xce/0x2f0 ... Call Trace: dump_stack_lvl+0x6c/0x8b print_address_description.constprop.0+0x48/0x70 kasan_report.cold+0x82/0xdb __asan_load4+0x6b/0x90 dvb_dmxdev_release+0xce/0x2f0 ... Allocated by task 7666: kasan_save_stack+0x23/0x50 __kasan_kmalloc+0x83/0xa0 kmem_cache_alloc_trace+0x22e/0x470 dvb_register_device+0x12f/0x980 dvb_dmxdev_init+0x1f3/0x230 ... Freed by task 7666: kasan_save_stack+0x23/0x50 kasan_set_track+0x20/0x30 kasan_set_free_info+0x24/0x40 __kasan_slab_free+0xf2/0x130 kfree+0xd1/0x5c0 dvb_register_device.cold+0x1ac/0x1fa dvb_dmxdev_init+0x1f3/0x230 ... When dvb_register_device() in dvb_dmxdev_init() fails, dvb_dmxdev_init() does not return a failure, and the memory pointed to by dvbdev or dvr_dvbdev is invalid at this point. If they are used subsequently, it will result in UFA or null-ptr-deref. If dvb_register_device() in dvb_dmxdev_init() fails, fix the bug by making dvb_dmxdev_init() return an error as well. Link: https://lore.kernel.org/linux-media/20211015085741.1203283-1-wanghai38@huawei.com Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
-
Martin Weber authored
support greyscale pix fmt input for coda9_jpeg_encoder. The hardware supports it, so allow V4L2 Mem2Mem JPEG Encoder use it as well. Tested on an i.MX6QP. [hverkuil: updated the Subject line as suggested by Philipp] Signed-off-by:
Martin Weber <martin.weber@br-automation.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Niklas Söderlund authored
The driver already has logic to detect if it fails to stop properly and report this error to the user. The driver however did not report the unused buffers or buffers given to the hardware (if any) with an error, the buffers where instead returned to user-space in the active state. Build on the existing detection of the error condition and correctly return the buffers with an error if it triggers. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Dorota Czaplejewicz authored
Neither imx_media_mbus_fmt_to_ipu_image nor imx_media_ipu_image_to_mbus_fmt were used anywhere. Signed-off-by:
Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 9cb2173e ("[media] media: Add stk1160 new driver (easycap replacement)") Cc: stable@vger.kernel.org # 3.7 Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Use the common control-message timeout define for the five-second timeouts. Fixes: 38f993ad ("V4L/DVB (8125): This driver adds support for the Sensoray 2255 devices.") Cc: stable@vger.kernel.org # 2.6.27 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: d855497e ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18") Cc: stable@vger.kernel.org # 2.6.18 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: a6c2ba28 ("[PATCH] v4l: 716: support for em28xx board family") Cc: stable@vger.kernel.org # 2.6.16 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: ab33d507 ("V4L/DVB (3376): Add cpia2 camera support") Cc: stable@vger.kernel.org # 2.6.17 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Note that the driver was multiplying some of the timeout values with HZ twice resulting in 3000-second timeouts with HZ=1000. Also note that two of the timeout defines are currently unused. Fixes: 2154be65 ("[media] redrat3: new rc-core IR transceiver device driver") Cc: stable@vger.kernel.org # 3.0 Signed-off-by:
-
