Better document a note on this header.

While here, better format dvb_ringbuffer_pkt_read_user()
to adjust it to CodingStyle.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Add documentation for v4l2-dev.h, and put it at v4l2-framework.rst,
where struct video_device is currently documented.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This header were poorly documented, and weren't using the
kernel-doc format. Document everything but the macros using
the right format.

While here, also fix the other comments to match the
Linux CodingStyle.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Fix all remaining media warnings with ReST that are fixable
without changing at the Sphinx code.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Even when the adapter is configured for CEC 1.4, we still check and
use the CEC 2.0 parts of struct cec_log_addrs. Although these aren't
used in CEC messages, the information contained in them is still of
use in the CEC framework itself, so keep this information.

Also zero the unused trailing features[] data and unused logical address
data so the contents isn't random data.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

For POLLOUT poll only checked if the adapter was configured, not
if there was room in the transmit queue. Add that check.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Just pass the transmitted CEC message to all CEC adapters.
This implements the Monitor All mode for vivid.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The main message loop checks if the physical address was valid, and if
not it is assumed that the adapter had been unconfigured.

However, this check is no longer correct, instead it should check
that both adap->is_configured and adap->is_configuring are false.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The size of the transmit queue was unlimited, which meant that
in non-blocking mode you could flood the CEC adapter with messages
to be transmitted.

Limit this to 18 messages.

Also print the number of pending transmits and the timeout value
in the status debugfs file.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Ensure that the unused part of the msg array is zeroed. This is
required by CEC 2.0 when receiving shorter messages than expected.
In that case the remaining bytes are assumed to be 0.

There are no such CEC messages yet, but it is required to be future proof.

And since we're doing it for received messages, do it for transmitted
messages as well. It's unambiguous this way.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The filehandle was set to NULL when in non-blocking mode or when
no reply is needed.

This is wrong: the filehandle is needed in non-blocking mode to ensure
that the result of the transmit can be obtained through CEC_RECEIVE.

And the 'reply' check was also incorrect since it should have checked the
timeout field (the reply can be 0). In any case, when in blocking mode
there is no need to set the fh to NULL either.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Before transmitting a message clear all status fields and always fill
in the sequence number. Make sure the sequence number is never 0.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

When CEC_RECEIVE returns a message the original timeout field
was overwritten. Restore the timeout field.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The conversion from DocBook required some fixes:

- Now, the C files with the exported symbols also need to be
  added. So, all headers need to be included twice: one to
  get the structs/enums/.. and another one for the functions;

- Notes should use the ReST tag, as kernel-doc doesn't
  recognizes it anymore;

- Identation needs to be fixed, as ReST uses it to identify
  when a format "tag" ends.

- Fix the cross-references at the media controller description.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Move the contents of the media section at
DocBooks/DocBook/device-drivers.tmpl to a new ReST book.

For now, the contents is kept as-is. Next patches will fix
the warnings and add cross-references that were removed due to
the conversion.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Now driver returns correct values for DVB-C:
 SNR (in dB)

[mchehab@s-opensource.com: fix a new function to be static]
Signed-off-by: NAbylay Ospan <aospan@netup.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

now driver returns correct values for DVB-C:
 BER (post_bit_count and post_bit_error values)
 UCB (count of uncorrected errors)
also, some code cleanup was done - checkpatch.pl now is happy
Signed-off-by: NAbylay Ospan <aospan@netup.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

DVB-C should use cxd2841er_read_agc_gain_c() to get the gain. The same
function is used for all DVB-C annex delivery systems.
Signed-off-by: NAbylay Ospan <aospan@netup.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The scale for ISDB-T was wrong too: it was inverted, and
on a relative scale.

Use a linear interpolation to make it look better.
The formula was empirically determined, using 3 frequencies
(175 MHz, 410 MHz and 800 MHz), measuring from -50dBm to
-12dBm in steps of 0.5dB.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Instead of using a relative frequency range, calibrate it to
show the results in dB. The callibration was done getting
samples with a signal generated from -50dBm to -12dBm,
incremented in steps of 0.5 dB, using 3 frequencies:
175 MHz, 410 MHz and 800 MHz. The modulated signal was
using QAM64, and it was used a linear interpolation of all
the results.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Currently, there's no stats for DVB-C. Let's at least return
signal strength. The scale is different than on DVB-T, so let's
use a relative scale, for now.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

What userspace expects is to receive both bit_error and bit_count
counters. So, instead of doing the division at the Kernel,
return the counters for userspace to handle it the way it
wants.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Appling the mask 0x0f to the immediate return of the call to
mb86a20s_readreg will always result in a positive value, meaning that the
check of ret < 0 will never work.  Instead, check for a -ve return value
first, and then mask val with 0x0f.

Kudos to Mauro Carvalho Chehab for spotting the mistake in my original fix.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This patch addresses CVE-2016-5400, a local DOS vulnerability caused by
a memory leak in the airspy usb device driver.

The vulnerability is triggered when more than 64 usb devices register
with v4l2 of type VFL_TYPE_SDR or VFL_TYPE_SUBDEV.A badusb device can
emulate 64 of these devices then through continual emulated
connect/disconnect of the 65th device, cause the kernel to run out of
RAM and crash the kernel.

The vulnerability exists in kernel versions from 3.17 to current 4.7.

The memory leak is caused by the probe function of the airspy driver
mishandeling errors and not freeing the corresponding control structures
when an error occours registering the device to v4l2 core.
Signed-off-by: NJames Patrick-Evans <james@jmp-e.com>
Cc: stable@vger.kernel.org # Up to Kernel 3.17
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Mention that the HDMI driver should pass on the physical address
to this driver, rather than requiring userspace to do this.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Cc: Kamil Debski <k.debski@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The CEC documentation has been converted to sphinx, so this
TODO item can be dropped.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Attempts to send CEC messages to yourself are detected in the framework and
returned with a NACK error. However, the tx_ts was never filled in that case.
So just set it.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Fix typo in vivid that caused all HDMI outputs to have the same
physical address.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

When calculate OUTPUT buffer size in vidioc_try_fmt, it will
add more size hw need in each plane.
But in mtk_vcodec_enc_set_default_params, it do not add
same size in each plane.
This makes v4l2-compliance test fail.
This patch fix the issue.
Signed-off-by: NTiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

There is really no reason to zero the reply and timeout fields if an
error occurs. This is a left-over from earlier versions where that
was used to signal errors, but this is now handled by the rx/tx_status
fields.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The newly added mtk-vcodec driver produces a number of warnings in an
ARM allmodconfig build, mainly since it assumes that dma_addr_t is
32-bit wide:

mtk-vcodec/venc/venc_vp8_if.c: In function 'vp8_enc_alloc_work_buf':
mtk-vcodec/venc/venc_vp8_if.c:212:191: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
mtk-vcodec/venc/venc_h264_if.c: In function 'h264_enc_alloc_work_buf':
mtk-vcodec/venc/venc_h264_if.c:297:190: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

This rearranges the format strings and type casts to what they should
have been in order to avoid the warnings. e0f80d8d ("[media]
mtk-vcodec: fix two compiler warnings") fixed some of the problems that
were introduced at the same time, but missed two others.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Instead of hardcoding a timeout, let userspace change it dynamically
by adding a s_timeout ops.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The redrat3 sends an usb packet to the host either when the minimum pause
or the timeout occurs, so we can always add a trailing space in our
processing.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

LIRC_SET_SEND_CARRIER should return 0 on success or -errno.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

When s_tx_mask is given an invalid bitmask, the number of transmitters
should be returned. See the LIRC_SET_TRANSMITTER_MASK lirc ioctl
documentation.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The value 5 of the EEPROM_TS_MODE register (meaning dual tuner presence) is
only valid for AF9035 devices. For IT9135 devices it is invalid and led to a
false positive dual tuner mode detection with PCTV 79e.
Therefore on non-AF9035 devices and with value 5 the driver now defaults to
single tuner mode and outputs a regarding info message to log.

This fixes Bugzilla bug #118561.
Reported-by: NMarc Duponcheel <marc@offline.be>
Signed-off-by: NStefan Pöschel <basic.master@gmx.de>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

If a system configures the Nuvoton chip to use the alternative
EFM IO address (CR_EFIR2) then after probing the primary EFM IO
address (CR_EFIR) this region is not released.

If a driver for another function of the Nuvoton Super I/O
chip uses the same probing mechanism then it will hang if
loaded after the nuvoton-cir driver.
This was reported for the nct6775 hwmon driver.

Fix this by properly releasing the region after probing CR_EFIR.
This regression was introduced with kernel 4.6 so cc it to stable.
Reported-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Tested-by: NAntti Seppälä <a.seppala@gmail.com>
Cc: <stable@vger.kernel.org> # 4.6.x-
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Don't free the object until the file handle has been closed.  Fixes
use-after-free bug which occurs when I disconnect my DVB-S received
while VDR is running.

This is a crash dump of such a use-after-free:

    general protection fault: 0000 [#1] SMP
    CPU: 0 PID: 2541 Comm: CI adapter on d Not tainted 4.7.0-rc1-hosting+ #49
    Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
    task: ffff880027d7ce00 ti: ffff88003d8f8000 task.ti: ffff88003d8f8000
    RIP: 0010:[<ffffffff812f3d1f>]  [<ffffffff812f3d1f>] dvb_ca_en50221_io_read_condition.isra.7+0x6f/0x150
    RSP: 0018:ffff88003d8fba98  EFLAGS: 00010206
    RAX: 0000000059534255 RBX: 000000753d470f90 RCX: ffff88003c74d181
    RDX: 00000001bea04ba9 RSI: ffff88003d8fbaf4 RDI: 3a3030a56d763fc0
    RBP: ffff88003d8fbae0 R08: ffff88003c74d180 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000000 R12: ffff88003c480e00
    R13: 00000000ffffffff R14: 0000000059534255 R15: 0000000000000000
    FS:  00007fb4209b4700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f06445f4078 CR3: 000000003c55b000 CR4: 00000000000006b0
    Stack:
     ffff88003d8fbaf4 000000003c2170c0 0000000000004000 0000000000000000
     ffff88003c480e00 ffff88003d8fbc80 ffff88003c74d180 ffff88003d8fbb8c
     0000000000000000 ffff88003d8fbb10 ffffffff812f3e37 ffff88003d8fbb00
    Call Trace:
     [<ffffffff812f3e37>] dvb_ca_en50221_io_poll+0x37/0xa0
     [<ffffffff8113109b>] do_sys_poll+0x2db/0x520

This is a backtrace of the kernel attempting to lock a freed mutex:

    #0  0xffffffff81083d40 in rep_nop () at ./arch/x86/include/asm/processor.h:569
    #1  cpu_relax () at ./arch/x86/include/asm/processor.h:574
    #2  virt_spin_lock (lock=<optimized out>) at ./arch/x86/include/asm/qspinlock.h:57
    #3  native_queued_spin_lock_slowpath (lock=0xffff88003c480e90, val=761492029) at kernel/locking/qspinlock.c:304
    #4  0xffffffff810d1a06 in pv_queued_spin_lock_slowpath (val=<optimized out>, lock=<optimized out>) at ./arch/x86/include/asm/paravirt.h:669
    #5  queued_spin_lock_slowpath (val=<optimized out>, lock=<optimized out>) at ./arch/x86/include/asm/qspinlock.h:28
    #6  queued_spin_lock (lock=<optimized out>) at include/asm-generic/qspinlock.h:107
    #7  __mutex_lock_common (use_ww_ctx=<optimized out>, ww_ctx=<optimized out>, ip=<optimized out>, nest_lock=<optimized out>, subclass=<optimized out>,
        state=<optimized out>, lock=<optimized out>) at kernel/locking/mutex.c:526
    #8  mutex_lock_interruptible_nested (lock=0xffff88003c480e88, subclass=<optimized out>) at kernel/locking/mutex.c:647
    #9  0xffffffff812f49fe in dvb_ca_en50221_io_do_ioctl (file=<optimized out>, cmd=761492029, parg=0x1 <irq_stack_union+1>)
        at drivers/media/dvb-core/dvb_ca_en50221.c:1210
    #10 0xffffffff812ee660 in dvb_usercopy (file=<optimized out>, cmd=761492029, arg=<optimized out>, func=<optimized out>) at drivers/media/dvb-core/dvbdev.c:883
    #11 0xffffffff812f3410 in dvb_ca_en50221_io_ioctl (file=<optimized out>, cmd=<optimized out>, arg=<optimized out>) at drivers/media/dvb-core/dvb_ca_en50221.c:1284
    #12 0xffffffff8112eddd in vfs_ioctl (arg=<optimized out>, cmd=<optimized out>, filp=<optimized out>) at fs/ioctl.c:43
    #13 do_vfs_ioctl (filp=0xffff88003c480e90, fd=<optimized out>, cmd=<optimized out>, arg=<optimized out>) at fs/ioctl.c:674
    #14 0xffffffff8112f30c in SYSC_ioctl (arg=<optimized out>, cmd=<optimized out>, fd=<optimized out>) at fs/ioctl.c:689
    #15 SyS_ioctl (fd=6, cmd=2148298626, arg=140734533693696) at fs/ioctl.c:680
    #16 0xffffffff8103feb2 in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:207
Signed-off-by: NMax Kellermann <max@duempel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The wait_event() call in dvb_unregister_frontend() waits synchronously
for other tasks to free a file descriptor, but it does that while
holding several mutexes.  That alone is a bad idea, but if one user
process happens to keep a (defunct) file descriptor open indefinitely,
the kernel will correctly detect a hung task:

    INFO: task kworker/0:1:314 blocked for more than 30 seconds.
          Not tainted 4.7.0-rc1-hosting+ #50
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    kworker/0:1     D ffff88003daf7a50     0   314      2 0x00000000
    Workqueue: usb_hub_wq hub_event
     ffff88003daf7a50 0000000000000296 ffff88003daf7a30 ffff88003fc13f98
     ffff88003dadce00 ffff88003daf8000 ffff88003e3fc010 ffff88003d48d4f8
     ffff88003e3b5030 ffff88003e3f8898 ffff88003daf7a68 ffffffff810cf860
    Call Trace:
     [<ffffffff810cf860>] schedule+0x30/0x80
     [<ffffffff812f88d3>] dvb_unregister_frontend+0x93/0xc0
     [<ffffffff8107a000>] ? __wake_up_common+0x80/0x80
     [<ffffffff813019c7>] dvb_usb_adapter_frontend_exit+0x37/0x70
     [<ffffffff81300614>] dvb_usb_exit+0x34/0xb0
     [<ffffffff81300d4a>] dvb_usb_device_exit+0x3a/0x50
     [<ffffffff81302dc2>] pctv452e_usb_disconnect+0x52/0x60
     [<ffffffff81295a07>] usb_unbind_interface+0x67/0x1e0
     [<ffffffff810609f3>] ? __blocking_notifier_call_chain+0x53/0x70
     [<ffffffff8127ba67>] __device_release_driver+0x77/0x110
     [<ffffffff8127c2d3>] device_release_driver+0x23/0x30
     [<ffffffff8127ab5d>] bus_remove_device+0x10d/0x150
     [<ffffffff8127879b>] device_del+0x13b/0x260
     [<ffffffff81299dea>] ? usb_remove_ep_devs+0x1a/0x30
     [<ffffffff8129468e>] usb_disable_device+0x9e/0x1e0
     [<ffffffff8128bb09>] usb_disconnect+0x89/0x260
     [<ffffffff8128db8d>] hub_event+0x30d/0xfc0
     [<ffffffff81059475>] process_one_work+0x1c5/0x4a0
     [<ffffffff8105940c>] ? process_one_work+0x15c/0x4a0
     [<ffffffff81059799>] worker_thread+0x49/0x480
     [<ffffffff81059750>] ? process_one_work+0x4a0/0x4a0
     [<ffffffff81059750>] ? process_one_work+0x4a0/0x4a0
     [<ffffffff8105f65e>] kthread+0xee/0x110
     [<ffffffff810400bf>] ret_from_fork+0x1f/0x40
     [<ffffffff8105f570>] ? __kthread_unpark+0x70/0x70
    5 locks held by kworker/0:1/314:
     #0:  ("usb_hub_wq"){......}, at: [<ffffffff8105940c>] process_one_work+0x15c/0x4a0
     #1:  ((&hub->events)){......}, at: [<ffffffff8105940c>] process_one_work+0x15c/0x4a0
     #2:  (&dev->mutex){......}, at: [<ffffffff8128d8cb>] hub_event+0x4b/0xfc0
     #3:  (&dev->mutex){......}, at: [<ffffffff8128bad2>] usb_disconnect+0x52/0x260
     #4:  (&dev->mutex){......}, at: [<ffffffff8127c2cb>] device_release_driver+0x1b/0x30

This patch removes the blocking wait, and postpones the kfree() call
until all file handles have been closed by using struct kref.
Signed-off-by: NMax Kellermann <max@duempel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Signed-off-by: NAayush Gupta <aayustark007@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>