- 27 Dec, 2012 40 commits
-
-
Mauro Carvalho Chehab authored
drivers/media/dvb-frontends/ts2020.c: In function 'ts2020_set_params': drivers/media/dvb-frontends/ts2020.c:126:47: warning: variable 'div4' set but not used [-Wunused-but-set-variable] drivers/media/dvb-frontends/ts2020.c: At top level: drivers/media/dvb-frontends/ts2020.c:262:5: warning: no previous prototype for 'ts2020_get_signal_strength' [-Wmissing-prototypes] Cc: Konstantin Dimitrov <kosio.dimitrov@gmail.com> Cc: Igor M. Liplianin <liplianin@me.by> Signed-off-by:Mauro Carvalho Chehab <mchehab@redhat.com>
-
Konstantin Dimitrov authored
make the other drivers take use of the separate ts2020 driver Signed-off-by:
Konstantin Dimitrov <kosio.dimitrov@gmail.com> Signed-off-by:
-
Konstantin Dimitrov authored
add separate ts2020 tuner driver Signed-off-by:
-
Konstantin Dimitrov authored
remove ts2020 tuner related code from ds3000 driver prepare ds3000 driver for using external tuner driver Signed-off-by:
-
Eddi De Pieri authored
Add support for Avermedia A835B and variants. Signed-off-by:
Eddi De Pieri <eddi@depieri.net> Cc: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Sasha Levin authored
There is no point in PTR_ERR()ing a NULL pointer, use a real error instead. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
Ezequiel Garcia authored
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:
Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by:
Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
Andy Walls <awalls@md.metrocast.net> Signed-off-by:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Ezequiel Garcia authored
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:
-
Hans Verkuil authored
I've always found it very confusing that the "Media ancillary drivers (tuners, sensors, i2c, frontends)" comment came after the "Autoselect" option. This patch moves it up and changes the "Autoselect" text to correspond more closely to the "Media ancillary drivers" comment. It also fixes two typos. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
John Törnblom authored
When the bttv driver is running without i2c_debug being set, the kernel log is being flooded with the string ">". This string is really a part of a debug message that is logged using several substrings protected by a conditional check. This patch adds the same conditional check to the leaked substring. Signed-off-by:
John Törnblom <john.tornblom@gmail.com> Signed-off-by:
-
Laurent Pinchart authored
drivers/media/platform/omap3isp/ispqueue.c:399:18: warning: 'pa' may be used uninitialized in this function [-Wuninitialized] This is a false positive but the compiler has no way to know about it, so initialize the variable to 0. drivers/media/platform/omap3isp/ispqueue.c:445:6: warning: 'vm_page_prot' may be used uninitialized in this function [-Wuninitialized] This is a false positive and the compiler should know better. Use uninitialized_var(). Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Patrice Chotard authored
Previously, demodulator and tuner attach was done in the demod_attach callback. Migrate the tuner part in the tuner_attach callback in ngene_info to do thing in right place. Signed-off-by:
Patrice Chotard <patricechotard@free.fr> Reviewed-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Patrice Chotard authored
Previously, gate control didn't work until drxd_init() execution. Migrate necessary set of commands in drxd_attach to allow gate control to be used by tuner which are accessible through i2c gate. Reported-by: frederic.mantegazza@gbiloba.org Signed-off-by:
-
Libin Yang authored
This patch replaces the global frame stats variables by using internal variables in mcam_camera structure. Signed-off-by:
Albert Wang <twang13@marvell.com> Signed-off-by:
Libin Yang <lbyang@marvell.com> Acked-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Konstantin Khlebnikov authored
During modiles initialization rc-core schedules work which calls request_module() several times to load ir-*-decoder modules, but it does not wait or cancel this work on module unloading. rc-core should use request_module_nowait() instead, because it anyway cannot load modules synchronously or cancel/wait pending work on unloading, because this leads to deadlock on modules_mutex between several "modprobe" processes. Signed-off-by:
Konstantin Khlebnikov <khlebnikov@openvz.org> Signed-off-by:
-
Laurent Pinchart authored
drivers/media/platform/omap3isp/ispcsiphy.c: In function ‘csiphy_routing_cfg’: drivers/media/platform/omap3isp/ispcsiphy.c:71:57: warning: ‘shift’ may be used uninitialized in this function [-Wuninitialized] drivers/media/platform/omap3isp/ispcsiphy.c:40:6: note: ‘shift’ was declared here The warning is a false positive but the compiler is right in complaining. Fix it by using the correct enum data type for the iface argument and adding a default case in the switch statement. Signed-off-by:
Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by:
-
Cyril Roelandt authored
Use uninterruptible mutex_lock in the release() file op to make sure all resources are properly freed when a process is being terminated. Returning -ERESTARTSYS has no effect for a terminating process and this may cause driver resources not to be released. This was found using the following semantic patch (http://coccinelle.lip6.fr/): <spml> @r@ identifier fops; identifier release_func; @@ static const struct v4l2_file_operations fops = { .release = release_func }; @depends on r@ identifier r.release_func; expression E; @@ static int release_func(...) { ... - if (mutex_lock_interruptible(E)) return -ERESTARTSYS; + mutex_lock(E); ... } </spml> Signed-off-by:
Cyril Roelandt <tipecaml@gmail.com> Acked-by:
-
Laurent Pinchart authored
Signed-off-by:
-
Laurent Pinchart authored
Add an entry for the mt9m032, mt9p031, mt9t001 and mt9v032 Aptina sensor drivers. Signed-off-by:
-
Antonio Ospite authored
This device was originally made by Twinhan/Azurewave[1] and sometimes named DTV-DVB UDTT7049, it could be also found in Italy under the name of Digicom Digitune-S[2], or Think Xtra Hollywood DVB-T USB2.0[3]. Components: Usb bridge: ULi M9206 Frontend: MT352CG Tuner: MT2060F The firmware can be downloaded with: $ ./Documentation/dvb/get_dvb_firmware vp7049 [1] http://www.azurewave.com/Support_Utility_Driver.asp [2] http://www.digicom.it/digisit/driver_link.nsf/driverprodotto?openform&prodotto=DigiTuneS [3] http://www.txitalia.it/prodotto.asp?prodotto=txhollywooddvttvSigned-off-by:
Antonio Ospite <ospite@studenti.unina.it> Signed-off-by:
-
