| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit f9c85ee67164b37f9296eab3b754e543e4e96a1c upstream.
Reported as a Kaffeine bug:
https://bugs.kde.org/show_bug.cgi?id=375811
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
On Kernel 4.9, the default is to not accept DMA on stack anymore
on x86 architecture. On other architectures, this has been a
requirement since Kernel 2.2. So, after this patch, this driver
should likely work fine on all archs.
Tested with USB ID 2040:5510: Hauppauge Windham
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit c739c0a7c3c2472d7562b8f802cdce44d2597c8b upstream.
A rare randconfig build failure shows up in this driver when
the CRC32 helper is not there:
drivers/media/built-in.o: In function `s5k4ecgx_s_power':
s5k4ecgx.c:(.text+0x9eb4): undefined reference to `crc32_le'
This adds the 'select' that all other users of this function have.
Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 79d6205a3f741c9fb89cfc47dfa0eddb1526726d upstream.
The s_stream() handler incorrectly writes the whole MISC_CTL register to
enable or disable the outputs, overriding the output pinmuxing
configuration. Fix it to only touch the output enable bits.
The CONF_SHARED_PIN register is also written by the same function,
resulting in muxing the INTREQ signal instead of the VBLK/GPCL signal on
the INTREQ/GPCL/VBLK pin. As the driver doesn't support interrupts this
is obviously incorrect, and breaks operation on other devices. Fix it by
removing the write.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit b4b2de386bbb6589d81596999d4a924928dc119b upstream.
The FID/GLCO/VLK/HVLK and INTREQ/GPCL/VBLK pins are muxed differently
depending on whether the input is an S-Video or composite signal. The
comment that explains the logic doesn't reflect the code. It appears
that the comment is incorrect, as disabling the output data bus in
composite mode makes no sense. Update the comment to match the code.
While at it define macros for the MISC_CTL register bits, the code is
too confusing with numerical values.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit aff808e813fc2d311137754165cf53d4ee6ddcc2 upstream.
The tvp5150 doesn't support format setting through the subdev pad API
and thus implements the set format handler as a get format operation.
The single handler, tvp5150_fill_fmt(), resets the device by calling
tvp5150_reset(). This causes malfunction as the device can be reset at
will, possibly from userspace when the subdev userspace API is enabled.
The reset call was added in commit ec2c4f3f93cb ("[media] media:
tvp5150: Add mbus_fmt callbacks"), probably as an attempt to set the
device to a known state before detecting the current TV standard.
However, the get format handler doesn't access the hardware to get the
TV standard since commit 963ddc63e20d ("[media] media: tvp5150: Add
cropping support"). There is thus no need to reset the device when
getting the format.
However, removing the tvp5150_reset() from the get/set format handlers
results in the function not being called at all if the bridge driver
doesn't use the .reset() operation. The operation is nowadays abused and
shouldn't be used, so shouldn't expect bridge drivers to call it. To
make sure the device is properly initialize, move the reset call from
the format handlers to the probe function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 48775cb73c2e26b7ca9d679875a6e570c8b8e124 upstream.
commit 73d5c5c864f4 ("[media] pctv452e: don't do DMA on stack") caused
a NULL pointer dereference which occurs when dvb_usb_init()
calls dvb_usb_device_power_ctrl() for the first time, before the
frontend has been attached. It also caused a recursive deadlock because
tt3650_ci_msg_locked() has already locked the mutex.
So, partially revert it, but move the buffer to the heap
(DMA capable), not to the stack (may not be DMA capable).
Instead of sharing one buffer which needs mutex protection,
do a new heap allocation for each call.
Fixes: commit 73d5c5c864f4 ("[media] pctv452e: don't do DMA on stack")
Signed-off-by: Max Kellermann <max.kellermann@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit c0026c7bfb95c250c3e34fde59f96ad72fd730d6 upstream.
Clock control indirectly requires access to MFC device, so call it only
if we are sure that the device exists in s5p_mfc_release function.
s5p_mfc_remove() calls s5p_mfc_final_pm(), which releases all PM related
resources, including clocks, so any call to clocks related functions
is not valid after s5p_mfc_final_pm().
Fixes: d695c12 ("[media] media: s5p-mfc fix invalid memory access from
s5p_mfc_release()")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 6b2bed891253c08e7f4c17dbd46b71fc87f22eef upstream.
The devm_ioremap_resource() returns error pointers, never NULL. The
platform_get_resource() returns NULL on error, never error pointers.
The error code needs to be set, as well. The current code returns
PTR_ERR(NULL) which is success.
Fixes: 57b2c0628b60 ("[media] st-hva: multi-format video encoder V4L2 driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jean-Christophe Trotin <jean-christophe.trotin@st.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 7ec03e60ef81c19b5d3a46dd070ee966774b860f upstream.
Function ite_set_carrier_params() uses variable use_demodulator after
having initialized it to false in some if branches, but this variable is
never set to true otherwise.
This bug has been found using clang -Wsometimes-uninitialized warning
flag.
Fixes: 620a32bba4a2 ("[media] rc: New rc-based ite-cir driver for
several ITE CIRs")
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit df94121f02ecce435d6b5277071eb94b764caa89 upstream.
It's not necessary to free memory allocated with devm_kzalloc
and using kfree leads to a double free.
Fixes: 7aae6e2df127 ("[media] Add GS1662 driver, a video serializer")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit ff681022c6639c194fbb6893c50ace9e52a44788 upstream.
Moving the pxa_camera driver from soc_camera lots the implied
VIDEO_V4L2 Kconfig dependency, and building the driver without
V4L2 results in a kernel that cannot link:
drivers/media/platform/pxa_camera.o: In function `pxa_camera_remove':
pxa_camera.c:(.text.pxa_camera_remove+0x10): undefined reference to `v4l2_clk_unregister'
pxa_camera.c:(.text.pxa_camera_remove+0x18): undefined reference to `v4l2_device_unregister'
drivers/media/platform/pxa_camera.o: In function `pxa_camera_probe':
pxa_camera.c:(.text.pxa_camera_probe+0x458): undefined reference to `v4l2_of_parse_endpoint'
drivers/media/v4l2-core/videobuf2-core.o: In function `__enqueue_in_driver':
drivers/media/v4l2-core/videobuf2-core.o: In function `vb2_core_streamon':
videobuf2-core.c:(.text.vb2_core_streamon+0x1b4): undefined reference to `v4l_vb2q_enable_media_source'
drivers/media/v4l2-core/videobuf2-v4l2.o: In function `vb2_ioctl_reqbufs':
videobuf2-v4l2.c:(.text.vb2_ioctl_reqbufs+0xc): undefined reference to `video_devdata'
This adds back an explicit dependency.
Fixes: 3050b9985024 ("[media] media: platform: pxa_camera: move pxa_camera out of soc_camera")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit c9205e18b41a6ef5ad73e1c4b86a78b2ea3ccb9b upstream.
devm_pinctrl_get() can fail so we should check for that.
Fixes: 0a6824bc10de ('[media] v4l2: blackfin: select proper pinctrl state in ppi_set_params if CONFIG_PINCTRL is enabled')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 1f5ecaf985c46889278f51fcb7bc143f60f4eb14 upstream.
'buf' is malloced in dibusb_rc_query() and should be freed before
leaving from the error handling cases, otherwise it will cause
memory leak.
Fixes: ff1c123545d7 ("[media] dibusb: handle error code on RC query")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit d183e4efcae8d88a2f252e546978658ca6d273cc upstream.
A break is missing resulting in the hue control enabling or disabling
the decode completely. Fix it.
Fixes: c43875f66140 ("[media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 5fc4b067ec082c3127e0156f800769b7e0dce078 upstream.
This fixes a lockup at device probing which happens on some solo6010
hardware samples. This is a regression introduced by commit e1ceb25a1569
("[media] SOLO6x10: remove unneeded register locking and barriers")
The observed lockup happens in solo_set_motion_threshold() called from
solo_motion_config().
This extra "flushing" is not fundamentally needed for every write, but
apparently the code in driver assumes such behaviour at last in some
places.
Actual fix was proposed by Hans Verkuil.
Fixes: e1ceb25a1569 ("[media] SOLO6x10: remove unneeded register locking and barriers")
Signed-off-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 3467c9a7e7f9209a9ecd8f9db65b04a323a13932 upstream.
s5p_mfc_alloc_memdev() function lacks proper releasing
of allocated device in case of reserved memory initialization
failure. This results in NULL pointer dereference:
[ 2.828457] Unable to handle kernel NULL pointer dereference at virtual address 00000001
[ 2.835089] pgd = c0004000
[ 2.837752] [00000001] *pgd=00000000
[ 2.844696] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 2.848680] Modules linked in:
[ 2.851722] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00002-gafa1b97 #878
[ 2.859357] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 2.865433] task: ef080000 task.stack: ef06c000
[ 2.869952] PC is at strcmp+0x0/0x30
[ 2.873508] LR is at platform_match+0x84/0xac
[ 2.877847] pc : [<c032621c>] lr : [<c03f65e8>] psr: 20000013
[ 2.877847] sp : ef06dea0 ip : 00000000 fp : 00000000
[ 2.889303] r10: 00000000 r9 : c0b34848 r8 : c0b1e968
[ 2.894511] r7 : 00000000 r6 : 00000001 r5 : c086e7fc r4 : eeb8e010
[ 2.901021] r3 : 0000006d r2 : 00000000 r1 : c086e7fc r0 : 00000001
[ 2.907533] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 2.914649] Control: 10c5387d Table: 4000404a DAC: 00000051
[ 2.920378] Process swapper/0 (pid: 1, stack limit = 0xef06c210)
[ 2.926367] Stack: (0xef06dea0 to 0xef06e000)
[ 2.930711] dea0: eeb8e010 c0c2d91c c03f4a6c c03f4a8c 00000000 c0c2d91c c03f4a6c c03f2fc8
[ 2.938870] dec0: ef003274 ef10c4c0 c0c2d91c ef10cc80 c0c21270 c03f3fa4 c09c1be8 c0c2d91c
[ 2.947028] dee0: 00000006 c0c2d91c 00000006 c0b3483c c0c47000 c03f5314 c0c2d908 c0b5fed8
[ 2.955188] df00: 00000006 c010178c 60000013 c0a4ef14 00000000 c06feaa0 ef080000 60000013
[ 2.963347] df20: 00000000 c0c095c8 efffca76 c0816b8c 000000d5 c0134098 c0b34848 c09d6cdc
[ 2.971506] df40: c0a4de70 00000000 00000006 00000006 c0c09568 efffca40 c0b5fed8 00000006
[ 2.979665] df60: c0b3483c c0c47000 000000d5 c0b34848 c0b005a4 c0b00d84 00000006 00000006
[ 2.987824] df80: 00000000 c0b005a4 00000000 c06fb4d8 00000000 00000000 00000000 00000000
[ 2.995983] dfa0: 00000000 c06fb4e0 00000000 c01079b8 00000000 00000000 00000000 00000000
[ 3.004142] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3.012302] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
[ 3.020469] [<c032621c>] (strcmp) from [<c03f65e8>] (platform_match+0x84/0xac)
[ 3.027672] [<c03f65e8>] (platform_match) from [<c03f4a8c>] (__driver_attach+0x20/0xb0)
[ 3.035654] [<c03f4a8c>] (__driver_attach) from [<c03f2fc8>] (bus_for_each_dev+0x54/0x88)
[ 3.043812] [<c03f2fc8>] (bus_for_each_dev) from [<c03f3fa4>] (bus_add_driver+0xe8/0x1f4)
[ 3.051971] [<c03f3fa4>] (bus_add_driver) from [<c03f5314>] (driver_register+0x78/0xf4)
[ 3.059958] [<c03f5314>] (driver_register) from [<c010178c>] (do_one_initcall+0x3c/0x16c)
[ 3.068123] [<c010178c>] (do_one_initcall) from [<c0b00d84>] (kernel_init_freeable+0x120/0x1ec)
[ 3.076802] [<c0b00d84>] (kernel_init_freeable) from [<c06fb4e0>] (kernel_init+0x8/0x118)
[ 3.084958] [<c06fb4e0>] (kernel_init) from [<c01079b8>] (ret_from_fork+0x14/0x3c)
[ 3.092506] Code: 1afffffb e12fff1e e1a03000 eafffff7 (e4d03001)
[ 3.098618] ---[ end trace 511bf9d750810709 ]---
[ 3.103207] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
This patch fixes this issue.
Fixes: c79667dd93b084fe412bcfe7fbf0ba43f7dec520 ("media: s5p-mfc: replace custom
reserved memory handling code with generic one")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit d930b5b5bf122a61952cfebabb1e618682a2631a upstream.
A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.
Fixes: 7908fad99a6c ("[media] mn88473: finalize driver")
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 365fe4e0ce218dc5ad10df17b150a366b6015499 upstream.
A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.
Fixes: 94d0eaa41987 ("[media] mn88472: move out of staging to media")
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried
to address the reported use-after-free by clearing the reference.
However, it's clearing the wrong pointer; it sets NULL to
priv->ctrl.fname, but it's anyway overwritten by the next line
memcpy(&priv->ctrl, p, sizeof(priv->ctrl)).
OTOH, the actual code accessing the freed string is the strcmp() call
with priv->fname:
if (!firmware_name[0] && p->fname &&
priv->fname && strcmp(p->fname, priv->fname))
free_firmware(priv);
where priv->fname points to the previous file name, and this was
already freed by kfree().
For fixing the bug properly, this patch does the following:
- Keep the copy of firmware file name in only priv->fname,
priv->ctrl.fname isn't changed;
- The allocation is done only when the firmware gets loaded;
- The kfree() is called in free_firmware() commonly
Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This file was converted to a separate module at commit 7a0786c19d65
("gp8psk: Fix DVB frontend attach"), because the DVB attach routines
require it to work. However, I forgot to copy the MODULE_foo() macros
from the original module, causing this warning:
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/dvb-frontends/gp8psk-fe.o
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: 7a0786c19d65 ("gp8psk: Fix DVB frontend attach")
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DVB binding schema at the DVB core assumes that the frontend is a
separate driver. Faling to do that causes OOPS when the module is
removed, as it tries to do a symbol_put_addr on an internal symbol,
causing craches like:
WARNING: CPU: 1 PID: 28102 at kernel/module.c:1108 module_put+0x57/0x70
Modules linked in: dvb_usb_gp8psk(-) dvb_usb dvb_core nvidia_drm(PO) nvidia_modeset(PO) snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore nvidia(PO) [last unloaded: rc_core]
CPU: 1 PID: 28102 Comm: rmmod Tainted: P WC O 4.8.4-build.1 #1
Hardware name: MSI MS-7309/MS-7309, BIOS V1.12 02/23/2009
Call Trace:
dump_stack+0x44/0x64
__warn+0xfa/0x120
module_put+0x57/0x70
module_put+0x57/0x70
warn_slowpath_null+0x23/0x30
module_put+0x57/0x70
gp8psk_fe_set_frontend+0x460/0x460 [dvb_usb_gp8psk]
symbol_put_addr+0x27/0x50
dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb]
From Derek's tests:
"Attach bug is fixed, tuning works, module unloads without
crashing. Everything seems ok!"
Reported-by: Derek <user.vdr@gmail.com>
Tested-by: Derek <user.vdr@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit bc29131ecb10 ("[media] gp8psk: don't do DMA on stack") fixed the
usage of DMA on stack, but the memcpy was wrong for gp8psk_usb_in_op().
Fix it.
From Derek's email:
"Fix confirmed using 2 different Skywalker models with
HD mpeg4, SD mpeg2."
Suggested-by: Johannes Stezenbach <js@linuxtv.org>
Fixes: bc29131ecb10 ("[media] gp8psk: don't do DMA on stack")
Tested-by: Derek <user.vdr@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The data_mutex is initialized too late, as it is needed for
each device driver's power control, causing an OOPS:
dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm state.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff846617af>] __mutex_lock_slowpath+0x6f/0x100 PGD 0
Oops: 0002 [#1] SMP
Modules linked in: dvb_usb_cinergyT2(+) dvb_usb
CPU: 0 PID: 2029 Comm: modprobe Not tainted 4.9.0-rc4-dvbmod #24
Hardware name: FUJITSU LIFEBOOK A544/FJNBB35 , BIOS Version 1.17 05/09/2014
task: ffff88020e943840 task.stack: ffff8801f36ec000
RIP: 0010:[<ffffffff846617af>] [<ffffffff846617af>] __mutex_lock_slowpath+0x6f/0x100
RSP: 0018:ffff8801f36efb10 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff88021509bdc8 RCX: 00000000c0000100
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88021509bdcc
RBP: ffff8801f36efb58 R08: ffff88021f216320 R09: 0000000000100000
R10: ffff88021f216320 R11: 00000023fee6c5a1 R12: ffff88020e943840
R13: ffff88021509bdcc R14: 00000000ffffffff R15: ffff88021509bdd0
FS: 00007f21adb86740(0000) GS:ffff88021f200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000215bce000 CR4: 00000000001406f0
Call Trace:
mutex_lock+0x16/0x25
cinergyt2_power_ctrl+0x1f/0x60 [dvb_usb_cinergyT2]
dvb_usb_device_init+0x21e/0x5d0 [dvb_usb]
cinergyt2_usb_probe+0x21/0x50 [dvb_usb_cinergyT2]
usb_probe_interface+0xf3/0x2a0
driver_probe_device+0x208/0x2b0
__driver_attach+0x87/0x90
driver_probe_device+0x2b0/0x2b0
bus_for_each_dev+0x52/0x80
bus_add_driver+0x1a3/0x220
driver_register+0x56/0xd0
usb_register_driver+0x77/0x130
do_one_initcall+0x46/0x180
free_vmap_area_noflush+0x38/0x70
kmem_cache_alloc+0x84/0xc0
do_init_module+0x50/0x1be
load_module+0x1d8b/0x2100
find_symbol_in_section+0xa0/0xa0
SyS_finit_module+0x89/0x90
entry_SYSCALL_64_fastpath+0x13/0x94
Code: e8 a7 1d 00 00 8b 03 83 f8 01 0f 84 97 00 00 00 48 8b 43 10 4c 8d 7b 08 48 89 63 10 4c 89 3c 24 41 be ff ff ff ff 48 89 44 24 08 <48> 89 20 4c 89 64 24 10 eb 1a 49 c7 44 24 08 02 00 00 00 c6 43 RIP [<ffffffff846617af>] __mutex_lock_slowpath+0x6f/0x100 RSP <ffff8801f36efb10>
CR2: 0000000000000000
So, move it to the struct dvb_usb_device and initialize it
before calling the driver's callbacks.
Reported-by: Jörg Otte <jrg.otte@gmail.com>
Tested-by: Jörg Otte <jrg.otte@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent rework accidentally left a debugging printk untouched while
changing the meaning of the variables, leading to an uninitialized
variable being printed:
drivers/media/i2c/ir-kbd-i2c.c: In function 'get_key_haup_common':
drivers/media/i2c/ir-kbd-i2c.c:62:2: error: 'toggle' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This prints the correct one instead, as we did before the patch.
Fixes: 00bb820755ed ("[media] rc: Hauppauge z8f0811 can decode RC6")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When receiving a nec repeat, ensure the correct scancode is repeated
rather than a random value from the stack. This removes the need for
the bogus uninitialized_var() and also fixes the warnings:
drivers/media/usb/dvb-usb/dib0700_core.c: In function ‘dib0700_rc_urb_completion’:
drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be used uninitialized in this function
[sean addon: So after writing the patch and submitting it, I've bought the
hardware on ebay. Without this patch you get random scancodes
on nec repeats, which the patch indeed fixes.]
Signed-off-by: Sean Young <sean@mess.org>
Tested-by: Sean Young <sean@mess.org>
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
"A series of fixup patches meant to fix the usage of DMA on stack, plus
one warning fixup"
* tag 'media/v4.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (32 commits)
[media] radio-bcm2048: don't ignore errors
[media] pctv452e: fix semicolon.cocci warnings
[media] flexcop-usb: don't use stack for DMA
[media] stk-webcam: don't use stack for DMA
[media] s2255drv: don't use stack for DMA
[media] cpia2_usb: don't use stack for DMA
[media] digitv: handle error code on RC query
[media] dw2102: return error if su3000_power_ctrl() fails
[media] nova-t-usb2: handle error code on RC query
[media] technisat-usb2: use DMA buffers for I2C transfers
[media] pctv452e: don't call BUG_ON() on non-fatal error
[media] pctv452e: don't do DMA on stack
[media] nova-t-usb2: don't do DMA on stack
[media] gp8psk: don't go past the buffer size
[media] gp8psk: don't do DMA on stack
[media] dtv5100: don't do DMA on stack
[media] dtt200u: handle USB control message errors
[media] dtt200u: don't do DMA on stack
[media] dtt200u-fe: handle errors on USB control messages
[media] dtt200u-fe: don't do DMA on stack
...
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
drivers/media/usb/dvb-usb/pctv452e.c:115:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
While here, remove a dead function calling usb_control_msg().
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| | |
There's no sense on decoding and generating a RC key code if
there was an error on the URB control message.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| | |
Instead of silently ignoring the error, return it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| | |
There's no sense on decoding and generating a RC key code if
there was an error on the URB control message.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
On this driver, most of the transfers are OK, but the I2C
one was using stack.
Reviewed-by: Patrick Boettcher <patrick.boettcher@posteo.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are some conditions on this driver that are tested with
BUG_ON() with are not serious enough to hang a machine.
So, just return an error if this happens.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Reviewed-by: Patrick Boettcher <patrick.boettcher@posteo.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Reviewed-by: Patrick Boettcher <patrick.boettcher@posteo.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| | |
Add checks to avoid going out of the buffer.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| | |
If something bad happens while an USB control message is
transfered, return an error code.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Reviewed-by: Patrick Boettcher <patrick.boettcher@posteo.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| | |
If something goes wrong, return an error code, instead of
assuming that everything went fine.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| | |
It is up to the frontend kthread to wait for lock.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Reviewed-by: Patrick Boettcher <patrick.boettcher@posteo.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| | |
There's no sense on decoding and generating a RC key code if
there was an error on the URB control message.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.
Reviewed-by: Patrick Boettcher <patrick.boettcher@posteo.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Be sure that I2C reads won't use stack by passing
a pointer to the state buffer, that we know it was
allocated via kmalloc, instead of relying on the buffer
allocated by an I2C client.
Reviewed-by: Patrick Boettcher <patrick.boettcher@posteo.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|