Patch 258c524b inadvertently removed the 'select RADIO_ISA' line for
the RADIO_RTRACK.

Fixes: 258c524b ("radio: allow building ISA drivers with COMPILE_TEST")
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

If dev_debug was active, then the code could return without unlocking the
core mutex. Replace the return with a 'goto unlock' to ensure proper unlocking.

Fixes: 73a11062 ("v4l2-core: push taking ioctl mutex down to ioctl handler")
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

When the subdevice doesn't provide s_power core ops callback, the
v4l2_subdev_call for s_power returns -ENOIOCTLCMD.  If the subdevice
doesn't have the special handling for its power saving mode, the s_power
isn't required.  So -ENOIOCTLCMD from the v4l2_subdev_call should be
ignored.

Actually the -ENOIOCTLCMD is ignored in this driver's suspend/resume,
but the others treat the -ENOIOCTLCMD as an error.

This prepares a wrapper function to ignore -ENOIOCTLCMD and replaces
all s_power calls with it.

This also adds warning message when s_power() is failed.

Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The TW9910 PDN gpio (power down) is listed as active high in the chip
manual. It turns out it is actually active low as when set to physical
level 0 it actually turns the video decoder power off.

Without this patch applied:
tw9910 0-0045: Product ID error 1f:2

With this patch applied:
tw9910 0-0045: tw9910 Product ID b:0

Fixes: commit "186c446f"
Signed-off-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

A failed memory client reset doesn't prevent VDE from resetting, hence
reset VDE regardless of preceding memory client resetting failure.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Testing randconfig builds after the return of the mmp ccic driver shows
a link error in some configurations:

drivers/media/platform/marvell-ccic/mcam-core.o: In function `mccic_register':
mcam-core.c:(.text+0x2e48): undefined reference to `vb2_dma_contig_memops'

A closer look at the mcam-core.c file reveals that we need to select
both VIDEOBUF2_DMA_CONTIG and VIDEOBUF2_VMALLOC, as already do for
VIDEO_CAFE_CCIC.

Fixes: 0a9c643c ("media: marvel-ccic: re-enable mmp-driver build")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Randconfig builds fail when one of the two is a built-in driver and
the other one is a loadable module:

drivers/media/platform/marvell-ccic/mcam-core.o: In function `mccic_register':
mcam-core.c:(.text+0x2594): undefined reference to `__this_module'
drivers/media/platform/marvell-ccic/mcam-core.o:(.rodata+0x50): undefined reference to `__this_module'

The problem is that mcam-core.c can not be built both ways at the smae
time. However, we can make kbuild take care of that by making the core
driver a separate module, which can be either built-in or loadable
as needed.
Making it a separate module requires exporting a few symbols and
adding the module license from the header.

Fixes: 0a9c643c ("media: marvel-ccic: re-enable mmp-driver build")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The addition of an extra operation to use the GET_INFO command
overwrites all existing flags from the uvc_ctrls table. This includes
setting all controls as supporting GET_MIN, GET_MAX, GET_RES, and
GET_DEF regardless of whether they do or not.

Move the initialisation of these control capabilities directly to the
uvc_ctrl_fill_xu_info() call where they were originally located in that
use case, and ensure that the new functionality in uvc_ctrl_get_flags()
will only set flags based on their reported capability from the GET_INFO
call.

Fixes: 859086ae ("media: uvcvideo: Apply flags from device to actual properties")

Cc: stable@vger.kernel.org
Signed-off-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: NGuennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

CineS2 V7(A) and Octopus CI S2 Pro/Advanced cards support faster TS speeds
on the card's contained stv0910 demodulator when their FPGA was updated
with a recent (>= 1.7, version number applies to all mentioned cards)
vendor firmware. Enable this faster TS speed on card port 0 (contained
demod) and parallel stv0910 connections when the card firmware is at least
1.7 or later.

Note: The mentioned cards and their demods are handled via the STV0910_PR
and STV0910_P tuner types. DuoFlex modules with such demodulators are
handled via the STV0910 (without suffix) types where such TS speed
increase doesn't technically make sense.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Tested-by: NRichard Scobie <rascobie@slingshot.co.nz>
Tested-by: NHelmut Auer <post@helmutauer.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Add a tsspeed config option to struct stv0910_cfg which can be used by
users of the driver to set the (parallel) TS speed (higher speeds enable
support for higher bitrate transponders). If tsspeed isn't set in the
config, it'll default to a sane value.

This commit also updates the two consumers of the stv0910 driver (ngene
and ddbridge) to have a default tsspeed in their stv0910_cfg templates.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Tested-by: NRichard Scobie <rascobie@slingshot.co.nz>
Tested-by: NHelmut Auer <post@helmutauer.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Fixes two checkpatch warnings

  WARNING: function definition argument 'xxx' should also have an identifier name

in the ddb_mci_attach() prototype definition. checkpatch keeps complaining
on the "int (**fn_set_input)" as it seems to have issues with the
ptr-to-ptr, though this probably needs fixing in checkpatch.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

In stop(), an (unlikely) out-of-bounds write error can occur when setting
the demod_in_use element indexed by state->demod to zero, as state->demod
isn't checked for being in the range of the array size of demod_in_use, and
state->demod maybe carrying the magic 0xff (demod unused) value. Prevent
this by checking state->demod not exceeding the array size before setting
the element value. To make the code a bit easier to read, replace the magic
value and the number of array elements with defines, and use them at a few
more places.

Detected by CoverityScan, CID#1468550 ("Out-of-bounds write")

Thanks to Colin for reporting the problem and providing an initial patch.

Fixes: daeeb131 ("media: ddbridge: initial support for MCI-based MaxSX8 cards")
Reported-by: NColin Ian King <colin.king@canonical.com>
Cc: Ralph Metzler <rjkm@metzlerbros.de>
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Since commit cb84343f ("media: lirc: do not call close() or open() on
unregistered devices") rc_open() will return -ENODEV if rcdev->registered
is false. Ensure this is set before we register the input device and the
lirc device, else we have a short window where the neither the lirc or
input device can be opened.

Fixes: cb84343f ("media: lirc: do not call close() or open() on unregistered devices")

Cc: stable@vger.kernel.org # v4.16+
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Doing writes when the device is disabled seems to be a NOOP.
For CIR device, we should enable it, initialize it, and then disable it
until it's opened. CIR_WAKE should always be enabled.
Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Core rc keeps track of the users - let's use it to tweak the code and
use the common code path on suspend/resume.
Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

It appears that we need to enable CIR device before attempting to touch
some of the registers. Previously, this was not a big issue, since we
were rarely seeing nvt_close() getting called.

Unfortunately, since commit cb84343f ("media: lirc: do not call close()
or open() on unregistered devices") the initial open() during probe from
rc_setup_rx_device() is no longer successful, which means that userspace
clients will actually end up calling nvt_open()/nvt_close(). Since
nvt_open() is broken, the device doesn't seem to work as expected.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199597Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: uvcvideo: Support UVC 1.5 video probe & commit controls

The length of UVC 1.5 video control is 48, and it is 34 for UVC 1.1.
Change it to 48 for UVC 1.5 device, and the UVC 1.5 device can be
recognized.

More changes to the driver are needed for full UVC 1.5 compatibility.
However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have been
reported to work well.

[laurent.pinchart@ideasonboard.com: Factor out code to helper function, update size checks]

Cc: stable@vger.kernel.org
Signed-off-by: Nming_qian <ming_qian@realsil.com.cn>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: NAna Guerrero Lopez <ana.guerrero@collabora.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

kref_init initializes the reference count to 1, not 0. This additional
reference is never released since the conversion to reference counters.
As a result, uvc_delete is not called anymore when UVC cameras are
disconnected.
Fix this by adding an additional kref_put in uvc_disconnect and in the
probe error path. This also allows to remove the temporary additional
reference in uvc_unregister_video.

Fixes: 9d15cd95 ("media: uvcvideo: Convert from using an atomic variable to a reference count")
Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The 50Hz and 60Hz power line frequency settings disable short (1/120s
and 1/100s) exposure times for banding filter (causing overexposed
image near lamps). No flicker setting enables them (when banding
filter is disabled and they're not used).

Seems that the logic is just the wrong way around.
(This bug came from the Windows driver.)
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Power line frequency settings for OV7648 sensor contain autogain
and exposure commands, affecting unrelated controls. Remove them.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The ZS0211 internal autogain causes pumping and flickering with OV7648
sensor on 0ac8:307b webcam.
Implement OV7648 autogain and exposure control and use that instead.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The ioctl serialization mutex (vdev->lock or q->lock for vb2 queues)
was taken at the highest level in v4l2-dev.c. This prevents more
fine-grained locking since at that level we cannot examine the ioctl
arguments, we can only do that after video_usercopy is called.

So push the locking down to __video_do_ioctl() and subdev_do_ioctl_lock().

This also allows us to make a few functions in v4l2-ioctl.c static and
video_usercopy() is no longer exported.

The locking scheme is not changed by this patch, just pushed down.
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

This driver is the only V4L driver that does not set unlocked_ioctl
to video_ioctl2.

The only thing that pvr2_v4l2_ioctl does besides calling video_ioctl2
is calling pvr2_hdw_commit_ctl(). Add pvr2_hdw_commit_ctl() calls to
the various ioctls that need this, and we can replace pvr2_v4l2_ioctl
by video_ioctl2.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Tested-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

This code has been there for nine years now, and it has been
working "good enough" since then [1].

Remove duplicate code by getting rid of the if-else statement.

[1] https://marc.info/?l=linux-kernel&m=152693550225081&w=2Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

If a CEC message was received and the RX interrupt was set, but
not yet processed, and a new transmit was issues, then the
transmit code would inadvertently clear the RX interrupt and
after that no new messages would ever be received.

Instead it should only clear TX interrupts since register 0x97
is a clear-on-write register.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

When a message was canceled it could return tx_status with
both OK and MAX_RETRIES set, which is illegal.

If a canceled message was waiting for a reply, then rx_status
wasn't updated, so set that as well.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Trivial fix to spelling mistake in name field
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The open() operation for the pxa_camera driver always calls s_power()
operation to put its subdevice sensor in normal operation mode, and the
release() operation always call s_power() operation to put the subdevice
in power saving mode.

This requires the subdevice sensor driver to keep track of its power
state in order to avoid putting the subdevice in power saving mode while
the device is still opened by some users.

Many subdevice drivers handle it by the boilerplate code that increments
and decrements an internal counter in s_power() like below:

	/*
	 * If the power count is modified from 0 to != 0 or from != 0 to 0,
	 * update the power state.
	 */
	if (sensor->power_count == !on) {
		ret = ov5640_set_power(sensor, !!on);
		if (ret)
			goto out;
	}

	/* Update the power count. */
	sensor->power_count += on ? 1 : -1;

However, some subdevice drivers don't handle it and may cause a problem
with the pxa_camera driver if the video device is opened by more than
two users at the same time.

Instead of propagating the boilerplate code for each subdevice driver
that implement s_power, this introduces an trick that many V4L2 drivers
are using with v4l2_fh_is_singular_file().
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

DMA requests must be blocked before resetting VDE HW, otherwise it is
possible to get a memory corruption or a machine hang. Use the reset
control provided by the Memory Controller to block DMA before resetting
the VDE HW.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

When the driver is configured in the "memcpy" dma-mode,
it uses vb2_vmalloc_memops, which is backed by a SLAB
allocator and so shouldn't be using GFP_DMA32.

Fix it.
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The DMA engine subsystem provides stubs for drivers
to build with !DMA_ENGINE. Drop the config dependency.
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The mutexes are not being destroyed in the release path. Fix it.
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Fix a trivial typo.
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various VIDEOBUF*DMA* symbols had to loose their dependencies on
    HAS_DMA, as they are selected by several individual drivers.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NMark Brown <broonie@kernel.org>
Acked-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

If we pick a very large "edid->blocks" value then the "edid->start_block
+ edid->blocks" addition could wrap around.

Fixes: ef834f78 ("[media] vivid: add the video capture and output parts")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The current logic makes Smatch to false-detect a Spectre variant 1
vulnerability. The problem is that it initializes an u32 indirectly
from user space input.

After trying to write a fixup, after a while I realized that, in
practice, this shouldn't be a problem, as an u32 is initialized
from u8, but it took some time to discover it.

So, do some code cleanup to make it clearer for both humans
and machines about the valid range for "op".

Fix this warning:
	drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() warn: potential spectre issue 'pin->error_inj_args'
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Some subdrivers access the gspca_dev->urb array in the completion handler.
To prevent use-after-free (actually, NULL dereferences) we need to
synchronously kill all the URBs before we release them.

In particular, this is currently the case for drivers such
as sn9c20x and sonixj, which access the gspca_dev->urb[0]
in the context of completion handler for *any* of the URBs.

This commit changes the destroy_urb implementation, so it kills
all URBs first, and then proceed to set the URBs to NULL in the
array and release them.
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Fix v4l2-compliance error: s_parm never set V4L2_CAP_TIMEPERFRAME.
Also various g/s_parm-related cleanups.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The last user of this 'feature' was the gspca driver. Now that
that driver has been converted to vb2 we can delete this code.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Zero the reserved capture/output array.

Zero the extendedmode (it is never used in drivers).

Clear all flags in capture/outputmode except for V4L2_MODE_HIGHQUALITY,
as that is the only valid flag.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>