Usage of these flags has been deprecated for nearly 4 years by:

    commit f77bf014
    Author: Sam Ravnborg <sam@neptun.(none)>
    Date:   Mon Oct 15 22:25:06 2007 +0200

        kbuild: introduce ccflags-y, asflags-y and ldflags-y

Moreover, these flags (at least EXTRA_CFLAGS) have been documented for command
line use. By default, gmake(1) do not override command line setting, so this is
likely to result in build failure or unexpected behavior.

Replace their usage by Kbuild's `{as,cc,ld}flags-y'.

Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: linux-media@vger.kernel.org
Signed-off-by: NArnaud Lacombe <lacombar@gmail.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Hi,

The following patch adds the IR code for the missing "OK" key to the Pinnacle
PCTV HD map. This map is now used by the PCTV 290e DVB-T2 device, whose remote
control has 26 buttons.
Signed-off-by: NChris Rankin <rankincj@yahoo.com>
Reviewed-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It seems just as necessary to free cam->vdev and cam in this error case as
in the next one.
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There were a several problems in this function:

1) Potential integer overflow in the comparison:
	if (fio.write_len + fio.read_len > 1028) {

2) If the user gave bogus values for write_len and read_len then
   returning -EINVAL is more appropriate than returning -ENOMEM.

3) wbuf was set to the address of an array and could never be NULL
   so I removed the pointless NULL check.

4) The call to vfree(wbuf) was improper.  That array is part of a
   larger struct and isn't allocated by itself.

5) flashio() can't actually fail, but we may as well add error
   handling in case this changes later.

6) In the default case where an ioctl is not implemented then
   returning -ENOTTY is more appropriate than returning -EFAULT.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch implements an i2c_gate_ctrl op for the cxd2820r. Thanks to Robert
Schlabbach for identifying the register address and field to set.

The old i2c intercept code that prefixed messages with a passthrough byte has
been removed and the PCTV nanoStick T2 290e entry in em28xx-dvb has been
updated appropriately.

Tested for DVB-T2 use; I would appreciate it if somebody with DVB-C capabilities
could test it as well - from inspection I cannot see any problems.

This is patch v2. It fixes some schoolboy style errors and removes superfluous
i2c entries in cxd2820r.h.
Signed-off-by: NSteve Kerrison <steve@stevekerrison.com>
Acked-by: NAntti Palosaari <crope@iki.fi>
Tested-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  identify a satellite receiver by its 'delivery_system' instead of
  'modulation', which may overlap between different delivery systems.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The ret = -EIO needs to be before the goto.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The goto needs to be moved after the assignment.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Tuners in general convert a high frequency carrier into an Intermediate
Frequency (IF).

Digital tuners like tda18271, xc3028, etc. generally allow changing the IF
frequency, although they generally have recommented settings for the IF.
Analog tuners, have a fixed IF frequency, that depends on the physical
characteristics of some analog components.

For digital tuners, it makes sense to have ways to configure IF,
via the tuner's configuration structure, like what's done inside the
tda18271-fe maps.

The demods need to know what IF is used by the tuner, as it will need
to convert internally from IF into baseband. Currently, the bridge driver
needs to fill a per-demod configuration struct for it, or pass it via
a dvb_attach parameter.

The tda18271 datasheet recommends to use different IF's for different
delivery system types and for different bandwidths.

The DRX-K demod also needs to know the IF frequency in order to work,
just like all other demods. However, as it accepts different delivery
systems (DVB-C and DVB-T), the IF may change if the standard and/or
bandwidth is changed.

So, the usual procedure of passing it via a config struct doesn't work.

One might try to code it as two separate IF frequencies, or even as a
table in function of the delivery system and the bandwidth, but this
will be messy.

So, it is better and simpler to just add a new callback for it and
require the tuners that can be used with MFE frontends like drx-k
to implement a new callback to return the used IF.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: NAntti Palosaari <crope@iki.fi>

Makes it more straight-forward to follow stack traces if the functions
don't have generic names. Using this as a crutch while trying to better
understand the lockdep warnings I get when loading the em28xx driver.

CC: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The one in-tree videobuf2-dma-sg driver (mmp-camera) has no need for a
kernel-space mapping of the buffers; one suspects that most other drivers
would not either.  The videobuf2-dma-sg module does the right thing if
buf->vaddr == NULL - it maps the buffer on demand if somebody needs it.  So
let's not map the buffer at allocation time; that will save a little CPU
time and a lot of address space in the vmalloc range.
Signed-off-by: NJonathan Corbet <corbet@lwn.net>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  - fepriv->parameters_out isn't protected by events->mtx, so
    move the call to fe->ops.get_frontend out of the locked area.
  - move the assignment of e->status into the locked area.

  - use direct assignment instead of memcpy.

  - use mutex_lock instead of mutex_lock_interruptible, because
    all code paths protected by this mutex won't block.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  the first event after an attempt to tune.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  enqueued before the frontend thread wakes up.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  Modify it to use the data given by the user.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Delete nontrivial initialization that is immediately overwritten by the
result of an allocation function.

The semantic match that makes this change is as follows:

// <smpl>
@@
type T;
identifier i;
expression e;
@@

(
T i = \(0\|NULL\|ERR_PTR(...)\);
|
-T i = e;
+T i;
)
... when != i
i = \(kzalloc\|kcalloc\|kmalloc\)(...);

// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In radio mode, no frequency offset should be used.

Instead of taking Thierry's patch that creates a separate function
to calculate the digital offset, it seemed better to just keep
everything at the same place.
Reported-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When loading the firmware, complete each chunk by sending an I2C flush
command to the frontend. Some devices like the tm6000 seem to require
this to properly flush the I2C buffers.

The current code in tm6000 executes the flush command once after each
I2C transfer, which slows down the firmware loading especially when
loading large BASE type images.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The ccdc block in the omap3isp produces events whenever it starts receiving
a new frame. A private HS_VS event was used for this previously. Now, the
generic V4L2_EVENT_FRAME_SYNC event is being used for the purpose.

This patch also provides the frame sequence number to user space.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJose Alberto Reguero <jareguero@telefonica.net>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch reduces the number of available choices for the notch filter type control
so that the standard-specific filter types cannot be selected. It is now limited to
being either 0 (4xFsc, the default) or 1 (square pixel optimized).
The patch also removes the initialization of this control from cx88_reset(), since
that is already done by init_controls(), which is called by cx8800_initdev().
Signed-off-by: NIstvan Varga <istvan_v@mailbox.hu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Use the more current logging styles with pr_fmt.
Remove now unnecessary private include.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Deduplicate printk formats to save ~20KB text.

$ size drivers/media/common/tuners/tda18271*o.*
   text	   data	    bss	    dec	    hex	filename
  10747	     56	   1920	  12723	   31b3	drivers/media/common/tuners/tda18271-common.o.new
  18889	     56	   3112	  22057	   5629	drivers/media/common/tuners/tda18271-common.o.old
  20561	    204	   4264	  25029	   61c5	drivers/media/common/tuners/tda18271-fe.o.new
  31093	    204	   6000	  37297	   91b1	drivers/media/common/tuners/tda18271-fe.o.old
   3681	   6760	    440	  10881	   2a81	drivers/media/common/tuners/tda18271-maps.o.new
   5631	   6760	    680	  13071	   330f	drivers/media/common/tuners/tda18271-maps.o.old
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Style issue.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to Thomas Gutzler for reporting this.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Cc: Thomas Gutzler <thomas.gutzler@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Convert array index from the loop bound to the loop index.

A simplified version of the semantic patch that fixes this problem is as

// <smpl>
@@
expression e1,e2,ar;
@@

for(e1 = 0; e1 < e2; e1++) { <...
  ar[
- e2
+ e1
  ]
  ...> }
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

[media] Add support for new revision of KNC 1 DVB-C cards. Using tda10024 instead of tda10023, which is compatible to tda10023 driver
Signed-off-by: NJulian Scheel <julian@jusst.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Driver for Kworld UB499-2T (id 1b80:e409)

The device driver has been named it913x, so that support for other family members
can be added later.

TODOs
Firmware support for other it913x devices.
Remote control support, there are two known types.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
[mchehab@redhat.com: Fix a merge conflict]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fronted and Tuner Driver for ITE IT913x Series with inital support for
IT9137 integrated demodulator and tuner device.

The driver is loosely based on AF9035 series. However, support is not intended for
this device specificity.

The IT9137 tuner has been tested on UHF bands, but VHF has only been simulated.

Possible TODO the tuner sections may be separated from the main driver. All future devices
should use the it913x_fe_script_loader for other tuner devices.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
[mchehab@redhat.com: Fix an issue at the Kconfig help]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Siano modules already had sms_dbg flag which is a module parameter which
sets the debug mode so module prints messages to dmesg for debugging.
The variable was static therefore apply only to the file which defines
the module. In modules as smsmdtv.ko that contain a few files, the debug
flag applied only for functions in that main file.
flag was changed to be non-static and therefore can be accessed by all
module files (although it is still not exported out of the module).
Signed-off-by: NDoron Cohen <doronc@siano-ms.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add note about recent updates coming from Microsoft's publicly available
specs on Windows Media Center remotes and receivers/transmitters.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Rather than dumping out hex values, lets print the actual calculated
frequency and period the hardware has been configured for. After this

[ 2643.276215] mceusb 3-1:1.0: tx data: 9f 07 (length=2)
[ 2643.276218] mceusb 3-1:1.0: Get carrier mode and freq
[ 2643.277206] mceusb 3-1:1.0: rx data: 9f 06 01 42 (length=4)
[ 2643.277209] mceusb 3-1:1.0: Got carrier of 37037 Hz (period 27us)

Matches up perfectly with the table in Microsoft's docs.

Of course, I've noticed on one of my devices that the MS-recommended
default value of 1 for carrier pre-scaler and 66 for carrier period was
butchered, and instead of converting 66 to hex (0x42 like above), they
put in 0x66, so the hardware reports a default carrier of 24390Hz.
Fortunately, I guess, this particular device is rx-only, but I wouldn't
put it past other hw to screw up here too.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

According to the specs, you can read the number of tx ports, number of
rx sensors, which tx ports have cables plugged into them, and which rx
sensors are active. In practice, most of my devices do seem to report
sane values for tx ports and rx sensors (but not all -- one without any
tx ports reports having them), and most report the active sensor
correctly, but only one of eight reports cabled tx ports correctly. So
for the most part, this is just for informational purposes.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Supposedly, there are essentially three different classes of devices
that are compatible with Microsoft's specs. First are the "legacy"
devices, which are built using Microsoft-provided hardware specs and
firmware. Second are "emulator" devices, which are built using custom
hardware and firmware, written to emulate Microsoft's firmware. Third
are "port" devices, which have their own device driver and firmware,
which provides compatible data to higher levels of the stack.

>From what I can tell, things like nuvoton-cir and fintek-cir are
essentially "port" devices -- their raw IR buffer format is very similar
to that of the mceusb devices. Now, within the mceusb driver, we have
three different "generations", which at first, seemed like maybe they
mapped to emulator versions. Unfortuantely, every single device I have
responds "illegal command" to the query to get firmware emulator version
from the hardware, which means they're either all emulator version 1, or
they're legacy devices, and our different "generations" aren't at all
related here. Though in theory, its possible the gen1 devices are
"legacy" devices and the rest are emulator v1. There are some useful
features of the v2 interface I was hoping to play with, but alas...
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

According to MS docs, the device firmware may halt after receiving an
unknown instruction, but that it should be possible to tell the firmware
to continue running by simply sending a device resume command. So lets
do that.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Its not uncommon for folks to force these bits enabled, because people
do want to wake their htpc kit via their remote. Lets just set the bits
for 'em.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>