This driver has a lot of printk continuation lines for
debugging purposes. Since commit 56387331
("Merge branch 'printk-cleanups"), this won't work as expected
anymore. So, let's add KERN_CONT to those lines.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

We have to unlock before returning -ENOMEM.

Fixes: 8dfbcc43 ('[media] xc2028: avoid use after free')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

If struct xc2028_config is passed without a firmware name,
the following trouble may happen:

[11009.907205] xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner
[11009.907491] ==================================================================
[11009.907750] BUG: KASAN: use-after-free in strcmp+0x96/0xb0 at addr ffff8803bd78ab40
[11009.907992] Read of size 1 by task modprobe/28992
[11009.907994] =============================================================================
[11009.907997] BUG kmalloc-16 (Tainted: G        W      ): kasan: bad access detected
[11009.907999] -----------------------------------------------------------------------------

[11009.908008] INFO: Allocated in xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd] age=0 cpu=3 pid=28992
[11009.908012] 	___slab_alloc+0x581/0x5b0
[11009.908014] 	__slab_alloc+0x51/0x90
[11009.908017] 	__kmalloc+0x27b/0x350
[11009.908022] 	xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd]
[11009.908026] 	usb_hcd_submit_urb+0x1e8/0x1c60
[11009.908029] 	usb_submit_urb+0xb0e/0x1200
[11009.908032] 	usb_serial_generic_write_start+0xb6/0x4c0
[11009.908035] 	usb_serial_generic_write+0x92/0xc0
[11009.908039] 	usb_console_write+0x38a/0x560
[11009.908045] 	call_console_drivers.constprop.14+0x1ee/0x2c0
[11009.908051] 	console_unlock+0x40d/0x900
[11009.908056] 	vprintk_emit+0x4b4/0x830
[11009.908061] 	vprintk_default+0x1f/0x30
[11009.908064] 	printk+0x99/0xb5
[11009.908067] 	kasan_report_error+0x10a/0x550
[11009.908070] 	__asan_report_load1_noabort+0x43/0x50
[11009.908074] INFO: Freed in xc2028_set_config+0x90/0x630 [tuner_xc2028] age=1 cpu=3 pid=28992
[11009.908077] 	__slab_free+0x2ec/0x460
[11009.908080] 	kfree+0x266/0x280
[11009.908083] 	xc2028_set_config+0x90/0x630 [tuner_xc2028]
[11009.908086] 	xc2028_attach+0x310/0x8a0 [tuner_xc2028]
[11009.908090] 	em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
[11009.908094] 	em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
[11009.908098] 	em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
[11009.908101] 	em28xx_register_extension+0xd9/0x190 [em28xx]
[11009.908105] 	em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
[11009.908108] 	do_one_initcall+0x141/0x300
[11009.908111] 	do_init_module+0x1d0/0x5ad
[11009.908114] 	load_module+0x6666/0x9ba0
[11009.908117] 	SyS_finit_module+0x108/0x130
[11009.908120] 	entry_SYSCALL_64_fastpath+0x16/0x76
[11009.908123] INFO: Slab 0xffffea000ef5e280 objects=25 used=25 fp=0x          (null) flags=0x2ffff8000004080
[11009.908126] INFO: Object 0xffff8803bd78ab40 @offset=2880 fp=0x0000000000000001

[11009.908130] Bytes b4 ffff8803bd78ab30: 01 00 00 00 2a 07 00 00 9d 28 00 00 01 00 00 00  ....*....(......
[11009.908133] Object ffff8803bd78ab40: 01 00 00 00 00 00 00 00 b0 1d c3 6a 00 88 ff ff  ...........j....
[11009.908137] CPU: 3 PID: 28992 Comm: modprobe Tainted: G    B   W       4.5.0-rc1+ #43
[11009.908140] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
[11009.908142]  ffff8803bd78a000 ffff8802c273f1b8 ffffffff81932007 ffff8803c6407a80
[11009.908148]  ffff8802c273f1e8 ffffffff81556759 ffff8803c6407a80 ffffea000ef5e280
[11009.908153]  ffff8803bd78ab40 dffffc0000000000 ffff8802c273f210 ffffffff8155ccb4
[11009.908158] Call Trace:
[11009.908162]  [<ffffffff81932007>] dump_stack+0x4b/0x64
[11009.908165]  [<ffffffff81556759>] print_trailer+0xf9/0x150
[11009.908168]  [<ffffffff8155ccb4>] object_err+0x34/0x40
[11009.908171]  [<ffffffff8155f260>] kasan_report_error+0x230/0x550
[11009.908175]  [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290
[11009.908179]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
[11009.908182]  [<ffffffff8155f5c3>] __asan_report_load1_noabort+0x43/0x50
[11009.908185]  [<ffffffff8155ea00>] ? __asan_register_globals+0x50/0xa0
[11009.908189]  [<ffffffff8194cea6>] ? strcmp+0x96/0xb0
[11009.908192]  [<ffffffff8194cea6>] strcmp+0x96/0xb0
[11009.908196]  [<ffffffffa13ba4ac>] xc2028_set_config+0x15c/0x630 [tuner_xc2028]
[11009.908200]  [<ffffffffa13bac90>] xc2028_attach+0x310/0x8a0 [tuner_xc2028]
[11009.908203]  [<ffffffff8155ea78>] ? memset+0x28/0x30
[11009.908206]  [<ffffffffa13ba980>] ? xc2028_set_config+0x630/0x630 [tuner_xc2028]
[11009.908211]  [<ffffffffa157a59a>] em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
[11009.908215]  [<ffffffffa157aa2a>] ? em28xx_dvb_init.part.3+0x37c/0x5cf4 [em28xx_dvb]
[11009.908219]  [<ffffffffa157a3a1>] ? hauppauge_hvr930c_init+0x487/0x487 [em28xx_dvb]
[11009.908222]  [<ffffffffa01795ac>] ? lgdt330x_attach+0x1cc/0x370 [lgdt330x]
[11009.908226]  [<ffffffffa01793e0>] ? i2c_read_demod_bytes.isra.2+0x210/0x210 [lgdt330x]
[11009.908230]  [<ffffffff812e87d0>] ? ref_module.part.15+0x10/0x10
[11009.908233]  [<ffffffff812e56e0>] ? module_assert_mutex_or_preempt+0x80/0x80
[11009.908238]  [<ffffffffa157af92>] em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
[11009.908242]  [<ffffffffa157a6ae>] ? em28xx_attach_xc3028.constprop.7+0x30d/0x30d [em28xx_dvb]
[11009.908245]  [<ffffffff8195222d>] ? string+0x14d/0x1f0
[11009.908249]  [<ffffffff8195381f>] ? symbol_string+0xff/0x1a0
[11009.908253]  [<ffffffff81953720>] ? uuid_string+0x6f0/0x6f0
[11009.908257]  [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0
[11009.908260]  [<ffffffff8104b02f>] ? print_context_stack+0x7f/0xf0
[11009.908264]  [<ffffffff812e9846>] ? __module_address+0xb6/0x360
[11009.908268]  [<ffffffff8137fdc9>] ? is_ftrace_trampoline+0x99/0xe0
[11009.908271]  [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0
[11009.908275]  [<ffffffff81240a70>] ? debug_check_no_locks_freed+0x290/0x290
[11009.908278]  [<ffffffff8104a24b>] ? dump_trace+0x11b/0x300
[11009.908282]  [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx]
[11009.908285]  [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290
[11009.908289]  [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590
[11009.908292]  [<ffffffff812404dd>] ? trace_hardirqs_on+0xd/0x10
[11009.908296]  [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx]
[11009.908299]  [<ffffffff822dcbb0>] ? mutex_trylock+0x400/0x400
[11009.908302]  [<ffffffff810021a1>] ? do_one_initcall+0x131/0x300
[11009.908306]  [<ffffffff81296dc7>] ? call_rcu_sched+0x17/0x20
[11009.908309]  [<ffffffff8159e708>] ? put_object+0x48/0x70
[11009.908314]  [<ffffffffa1579f11>] em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
[11009.908317]  [<ffffffffa13e81f9>] em28xx_register_extension+0xd9/0x190 [em28xx]
[11009.908320]  [<ffffffffa0150000>] ? 0xffffffffa0150000
[11009.908324]  [<ffffffffa0150010>] em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
[11009.908327]  [<ffffffff810021b1>] do_one_initcall+0x141/0x300
[11009.908330]  [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40
[11009.908333]  [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590
[11009.908337]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
[11009.908340]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
[11009.908343]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
[11009.908346]  [<ffffffff8155ea37>] ? __asan_register_globals+0x87/0xa0
[11009.908350]  [<ffffffff8144da7b>] do_init_module+0x1d0/0x5ad
[11009.908353]  [<ffffffff812f2626>] load_module+0x6666/0x9ba0
[11009.908356]  [<ffffffff812e9c90>] ? symbol_put_addr+0x50/0x50
[11009.908361]  [<ffffffffa1580037>] ? em28xx_dvb_init.part.3+0x5989/0x5cf4 [em28xx_dvb]
[11009.908366]  [<ffffffff812ebfc0>] ? module_frob_arch_sections+0x20/0x20
[11009.908369]  [<ffffffff815bc940>] ? open_exec+0x50/0x50
[11009.908374]  [<ffffffff811671bb>] ? ns_capable+0x5b/0xd0
[11009.908377]  [<ffffffff812f5e58>] SyS_finit_module+0x108/0x130
[11009.908379]  [<ffffffff812f5d50>] ? SyS_init_module+0x1f0/0x1f0
[11009.908383]  [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14
[11009.908394]  [<ffffffff822e6936>] entry_SYSCALL_64_fastpath+0x16/0x76
[11009.908396] Memory state around the buggy address:
[11009.908398]  ffff8803bd78aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[11009.908401]  ffff8803bd78aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[11009.908403] >ffff8803bd78ab00: fc fc fc fc fc fc fc fc 00 00 fc fc fc fc fc fc
[11009.908405]                                            ^
[11009.908407]  ffff8803bd78ab80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[11009.908409]  ffff8803bd78ac00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[11009.908411] ==================================================================

In order to avoid it, let's set the cached value of the firmware
name to NULL after freeing it. While here, return an error if
the memory allocation fails.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Bellow is yelling. Ok, sometimes the code is yells a lot, but
but this is not the case there ;)
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

As reported by cocinelle:

drivers/media/tuners/tuner-xc2028.c:182:2-18: code aligned with following code on line 183
drivers/media/tuners/tuner-xc2028.c:184:2-19: code aligned with following code on line 185
drivers/media/tuners/tuner-xc2028.c:186:2-19: code aligned with following code on line 187
drivers/media/tuners/tuner-xc2028.c:188:2-17: code aligned with following code on line 189
drivers/media/tuners/tuner-xc2028.c:190:2-19: code aligned with following code on line 191
drivers/media/tuners/tuner-xc2028.c:192:2-19: code aligned with following code on line 193
drivers/media/tuners/tuner-xc2028.c:194:2-18: code aligned with following code on line 195
drivers/media/tuners/tuner-xc2028.c:196:2-17: code aligned with following code on line 197
drivers/media/tuners/tuner-xc2028.c:198:2-18: code aligned with following code on line 199
drivers/media/tuners/tuner-xc2028.c:200:2-19: code aligned with following code on line 201
drivers/media/tuners/tuner-xc2028.c:202:2-18: code aligned with following code on line 203
drivers/media/tuners/tuner-xc2028.c:204:2-16: code aligned with following code on line 205
drivers/media/tuners/tuner-xc2028.c:206:2-20: code aligned with following code on line 207
drivers/media/tuners/tuner-xc2028.c:208:2-17: code aligned with following code on line 209
drivers/media/tuners/tuner-xc2028.c:210:2-18: code aligned with following code on line 211
drivers/media/tuners/tuner-xc2028.c:212:2-18: code aligned with following code on line 213
drivers/media/tuners/tuner-xc2028.c:214:2-18: code aligned with following code on line 215
drivers/media/tuners/tuner-xc2028.c:216:2-16: code aligned with following code on line 217
drivers/media/tuners/tuner-xc2028.c:218:2-18: code aligned with following code on line 219
drivers/media/tuners/tuner-xc2028.c:220:2-20: code aligned with following code on line 221
drivers/media/tuners/tuner-xc2028.c:222:2-21: code aligned with following code on line 223
drivers/media/tuners/tuner-xc2028.c:224:2-20: code aligned with following code on line 225
drivers/media/tuners/tuner-xc2028.c:226:2-23: code aligned with following code on line 227
drivers/media/tuners/tuner-xc2028.c:228:2-23: code aligned with following code on line 229
drivers/media/tuners/tuner-xc2028.c:230:2-22: code aligned with following code on line 231
drivers/media/tuners/tuner-xc2028.c:232:2-24: code aligned with following code on line 233
drivers/media/tuners/tuner-xc2028.c:234:2-19: code aligned with following code on line 235
drivers/media/tuners/tuner-xc2028.c:236:2-19: code aligned with following code on line 237
drivers/media/tuners/tuner-xc2028.c:238:2-20: code aligned with following code on line 239
drivers/media/tuners/tuner-xc2028.c:240:2-19: code aligned with following code on line 241
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Coverity CID 1196501: Missing break in switch (MISSING_BREAK)

I introduced that bug recently by commit
96a5b3a8.
As a result, it will flood unintentionally error message to log.

Reported-by: <scan-admin@coverity.com>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

There is now new tuner types which are not handled on that switch-case.
Print error if unknown tuner type is meet.

drivers/media/tuners/tuner-xc2028.c: In function ‘generic_set_freq’:
drivers/media/tuners/tuner-xc2028.c:1037:2: warning: enumeration value ‘V4L2_TUNER_ADC’ not handled in switch [-Wswitch]
  switch (new_type) {
  ^
drivers/media/tuners/tuner-xc2028.c:1037:2: warning: enumeration value ‘V4L2_TUNER_RF’ not handled in switch [-Wswitch]

Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

That removes those timeout errors:

[ 3675.930940] xc2028 19-0061: Device is Xceive 3028 version 1.0, firmware version 2.7
[ 3676.060487] xc2028 19-0061: divisor= 00 00 8d d0 (freq=567.250)
[ 3676.349449] xc2028 19-0061: Putting xc2028/3028 into poweroff mode.
[ 3698.247645] xc2028 19-0061: xc2028_get_reg 0002 called
[ 3698.253276] em2860 #0: I2C transfer timeout on writing to addr 0xc2
[ 3698.253301] xc2028 19-0061: i2c input error: rc = -121 (should be 2)
[ 3698.253327] xc2028 19-0061: xc2028_signal called
[ 3698.253339] xc2028 19-0061: xc2028_get_reg 0002 called
[ 3698.259283] em2860 #0: I2C transfer timeout on writing to addr 0xc2
[ 3698.259312] xc2028 19-0061: i2c input error: rc = -121 (should be 2)
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Only send a power down command for the device if it is not already
in power down state. That prevents a timeout when trying to talk
with the device.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This macro is not used. remove it.
Reviewed-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
	drivers/media/tuners/tuner-xc2028.c:651:1: warning: 'load_firmware' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this driver, the maximum limit is 80, used only
on tm6000 driver. This limit is due to the size of the USB control URBs.
Ok, it would be theoretically possible to use a bigger size on PCI
devices, but the firmware load time is already good enough. Anyway,
if some usage requires more, it is just a matter of also increasing
the buffer size at load_firmware().
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

drivers/media/tuners/tuner-xc2028.c:575:24: warning: cast to restricted __le16
drivers/media/tuners/tuner-xc2028.c:686:21: warning: cast to restricted __le16
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

kfree on NULL pointer is a no-op.
Signed-off-by: NSyam Sidhardhan <s.syam@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy(&(to), &(from), E);
+to = from;
// </smpl>
Signed-off-by: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Move the tuners one level up, as the "common" directory will be used
by drivers that are shared between more than one driver.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

>From 59306435992d9349f10ad82a8adf14d98becbbe8 Mon Sep 17 00:00:00 2001
Signed-off-by: NHans Petter Selasky <hselasky@c2i.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We need to do a mutex_unlock(&priv->lock) before returning.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We intended to do a compare here, not an assignment.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When tuner-xc2028 is not compiled as a module, dracut will
need to copy the firmware inside the initfs image.

So, use MODULE_FIRMWARE() to indicate such need.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Implement API support to return AFC frequency shift, as this device
supports it. The only other driver that implements it is tda9887,
and the frequency there is reported in Hz. So, use Hz also for this
tuner.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are several bugs at the signal strength algorithm:

	- It is using logical OR, instead of bit OR;
	- It doesn't wait up to 18 ms as it should;
	- the strength range is not ok.

Rework on it, in order to make it work.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Change the firmware logic to use request_firmware_nowait(), and
to preserve the loaded firmwares in memory, to reduce the risk
of troubles with buggy userspace apps.

With this change, while the firmware is being loaded, the driver
will return -EAGAIN to any calls. If, for some reason, firmware
failed to be loaded from userspace, it will return -ENODEV.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMiroslav Slugen <thunder.mmm@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch replaces the previous one proposed in the thread "xc3028:
force reload of DTV7 firmware in VHF band with Zarlink demodulator",
at the linux-media@vger.kernel.org ML.

The problem is that the firmware DTV78 works fine in UHF band (8 MHz
bandwidth) but is not working at all in VHF band (7 MHz bandwidth).
Reading the comments inside the code, I figured out that the real
problem could be connected to the formula used to calculate the center
frequency offset in VHF band.

In fact, removing this adjustment fixes the problem:

		if ((priv->cur_fw.type & DTV78) && freq < 470000000)
			offset -= 500000;

This is coherent to what was implemented for the DTV7 firmware by an
Australian user:

		if (priv->cur_fw.type & DTV7)
			offset += 500000;

In the end, now the center frequency is the same for all firmwares
(DTV7, DTV8, DTV78) and doesn't depend on channel bandwidth.

The final code looks clean and simple, and there is no need for any
"magic" adjustment:

		if (priv->cur_fw.type & DTV6)
			offset = 1750000;
		else	/* DTV7 or DTV8 or DTV78 */
			offset = 2750000;
Signed-off-by: NGianluca Gennari <gennarone@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is a big patch, yet trivial: now that all tuners use the DVBv5
way to pass parameters (e. g. via fe->dtv_property_cache), the
extra parameter can be removed from set_params() call.

After this change, very few DVBv3 specific stuff are left at the
tuners.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.

The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix lock bit to better indicate signal strength, from 4096 to
65535.
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>

drivers/media/common/tuners/tuner-xc2028.c: In function 'generic_set_freq':
drivers/media/common/tuners/tuner-xc2028.c:936:15: warning: comparison between 'enum tuner_mode' and 'enum v4l2_tuner_type'

Argument type was enum tuner_mode, but should have been enum v4l2_tuner_type.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A few places used T_DIGITAL_TV internally. Remove the usage of this
obsolete mode mask.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

My Hauppauge WinTV HVR-1400 needs sometimes more then only one retry to load the firmware successfully.
Signed-off-by: NAlina Friedrichsen <x-alina@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix a regression in the firmware loading time where it went from 1080 ms to
4700 ms.  This was noticed when the em28xx based HVR-950 took noticably longer
to load the driver.

Regression introduced in hg 12824.  The developer added an msleep() call with
an argument based on a newly introduced xc3028_ctrl field, which is left
initialized to zero for pretty much every board that is currently supported.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

tm6000 sometimes can't read from i2c, but this is currently required for
tuner-xc2028 to work.

This patch adds an option to tuner-xc2028 to not rely on i2c reading.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>