kernel/linux.git/drivers/media, branch v4.8.16

xc2028: Fix use-after-free bug properly

2016-12-02T08:10:33+00:00

commit 22a1e7783e173ab3d86018eb590107d68df46c11 upstream. 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') Signed-off-by: Takashi Iwai Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

dib0700: fix nec repeat handling

2016-11-18T09:51:44+00:00

commit ba13e98f2cebd55a3744c5ffaa08f9dca73bf521 upstream. 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 Tested-by: Sean Young Signed-off-by: Arnd Bergmann Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

v4l: vsp1: Prevent pipelines from running when not streaming

2016-11-10T15:38:57+00:00

commit e4e70a147a48618a36ae1b81c641516cb9d45993 upstream. Pipelines can only be run if all their video nodes are streaming. Commit b4dfb9b35a19 ("[media] v4l: vsp1: Stop the pipeline upon the first STREAMOFF") fixed the pipeline stop sequence, but introduced a race condition that makes it possible to run a pipeline after stopping the stream on a video node by queuing a buffer on the other side of the pipeline. Fix this by clearing the buffers ready flag when stopping the stream, which will prevent the QBUF handler from running the pipeline. Fixes: b4dfb9b35a19 ("[media] v4l: vsp1: Stop the pipeline upon the first STREAMOFF") Reported-by: Kieran Bingham Tested-by: Kieran Bingham Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

cx231xx: can't proceed if I2C bus register fails

2016-10-28T07:45:24+00:00

commit 461af077d349b11106ca084e9ef2973a753d33ff upstream. The driver should not ignore errors while registering the I2C bus, as this device can't even minimally work without the buses, as it uses those buses internally to talk with the several IP blocks inside the chip. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

cx231xx: fix GPIOs for Pixelview SBTVD hybrid

2016-10-28T07:45:24+00:00

commit 24b923f073ac37eb744f56a2c7f77107b8219ab2 upstream. This device uses GPIOs: 28 to switch between analog and digital modes: on digital mode, it should be set to 1. The code that sets it on analog mode is OK, but it misses the logic that sets it on digital mode. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

cx231xx: don't return error on success

2016-10-28T07:45:24+00:00

commit 1871d718a9db649b70f0929d2778dc01bc49b286 upstream. The cx231xx_set_agc_analog_digital_mux_select() callers expect it to return 0 or an error. Returning a positive value makes the first attempt to switch between analog/digital to fail. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

mb86a20s: fix demod settings

2016-10-28T07:45:24+00:00

commit 505a0ea706fc1db4381baa6c6bd2e596e730a55e upstream. With the current settings, only one channel locks properly. That's likely because, when this driver was written, Brazil were still using experimental transmissions. Change it to reproduce the settings used by the newer drivers. That makes it lock on other channels. Tested with both PixelView SBTVD Hybrid (cx231xx-based) and C3Tech Digital Duo HDTV/SDTV (em28xx-based) devices. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

mb86a20s: fix the locking logic

2016-10-28T07:45:24+00:00

commit dafb65fb98d85d8e78405e82c83e81975e5d5480 upstream. On this frontend, it takes a while to start output normal TS data. That only happens on state S9. On S8, the TS output is enabled, but it is not reliable enough. However, the zigzag loop is too fast to let it sync. As, on practical tests, the zigzag software loop doesn't seem to be helping, but just slowing down the tuning, let's switch to hardware algorithm, as the tuners used on such devices are capable of work with frequency drifts without any help from software. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

[media] cx23885/saa7134: assign q->dev to the PCI device

2016-09-19T15:38:05+00:00

Fix a regression caused by commit 2bc46b3ad3c1 ("[media] media/pci: convert drivers to use the new vb2_queue dev field"). Three places where q->dev should be set were missed, causing a WARN. Fixes: 2bc46b3ad3c1 ("[media] media/pci: convert drivers to use the new vb2_queue dev field"). Signed-off-by: Hans Verkuil Reported-by: Marton Balint Signed-off-by: Mauro Carvalho Chehab

[media] rcar-fcp: Make sure rcar_fcp_enable() returns 0 on success

2016-09-15T12:02:16+00:00

When resuming from suspend-to-RAM on r8a7795/salvator-x: dpm_run_callback(): pm_genpd_resume_noirq+0x0/0x90 returns 1 PM: Device fe940000.fdp1 failed to resume noirq: error 1 dpm_run_callback(): pm_genpd_resume_noirq+0x0/0x90 returns 1 PM: Device fe944000.fdp1 failed to resume noirq: error 1 dpm_run_callback(): pm_genpd_resume_noirq+0x0/0x90 returns 1 PM: Device fe948000.fdp1 failed to resume noirq: error 1 According to its documentation, rcar_fcp_enable() returns 0 on success or a negative error code if an error occurs. Hence fdp1_pm_runtime_resume() and vsp1_pm_runtime_resume() forward its return value to their callers. However, rcar_fcp_enable() forwards the return value of pm_runtime_get_sync(), which can actually be 1 on success, leading to the resume failure above. To fix this, consider only negative values returned by pm_runtime_get_sync() to be failures. Fixes: 7b49235e83b2347c ("[media] v4l: Add Renesas R-Car FCP driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab