- 01 Jan, 2013 1 commit
-
-
Ezequiel Garcia authored
This situation is not even an error condition so it's stupid to BUG_ON. Learn the lesson: http://permalink.gmane.org/gmane.linux.kernel/1347333Signed-off-by:
Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 28 Dec, 2012 7 commits
-
-
Igor M. Liplianin authored
Tuner part of Montage rs2000 chip is similar to ts2020 tuner. Patch to use ts2020 code. [mchehab@redhat.com: a few CodingStyle fixes] Signed-off-by:
Igor M. Liplianin <liplianin@me.by> Signed-off-by:
-
Igor M. Liplianin authored
TeVii s660 and others have LED for lock indication. Let's use it in right order. Signed-off-by:
-
Igor M. Liplianin authored
Trivial patch to implement SNR, BER, UCB counter for Montage rs2000 demod. Signed-off-by:
-
Igor M. Liplianin authored
Patch to select rs2000 module to compile automatically for TeVii S421 and S632 cards. Signed-off-by:
-
Kirill Smelkov authoredMost of *_ops and other structures in vivi.c were already declared const but some have not. Constify and code/data will take less space: $ size drivers/media/platform/vivi.o text data bss dec hex filename before: 12569 248 8 12825 3219 drivers/media/platform/vivi.o after: 12308 20 8 12336 3030 drivers/media/platform/vivi.o i.e. vivi.o is now ~500 bytes less. Signed-off-by:
Kirill Smelkov <kirr@navytux.spb.ru>
Signed-off-by: -
Alexey Klimov authored
Don't let Masterkit MA901 USB radio be handled by usb hid drivers. This device will be handled by radio-ma901.c driver. Signed-off-by:
Alexey Klimov <klimov.linux@gmail.com> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Alexey Klimov authored
This patch creates a new usb-radio driver, radio-ma901.c, that supports Masterkit MA 901 USB FM radio devices. This device plugs into both the USB and an analog audio input or headphones, so this thing only deals with initialization and frequency setting. Signed-off-by:
-
- 27 Dec, 2012 32 commits
-
-
Mauro Carvalho Chehab authored
Select is evil as it has issues with dependencies. Better to convert it to use depends on. That fixes a breakage with out-of-tree compilation of the media tree. Signed-off-by: -
Sachin Kamat authored
versioncheck script complains about missing linux/version.h header file. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Dan Carpenter authored
Smatch complainst that the call to mantis_evmgr_exit() dereferences "ca" but then we check it for NULL on the next line. I've moved the NULL check forward to avoid that. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Igor M. Liplianin authored
One register needs to be changed to TS to work. So we use separate inittab. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Igor M. Liplianin authored
DVB-S chip is Montage m88rs2000, so initial patch is simple. Signed-off-by:
-
Rémi Cardona authored
- if kmalloc() returns NULL, we can return immediately without trying to kfree() a NULL pointer. - if i2c_transfer() fails, error out immediately instead of trying to upload the remaining bytes of the firmware. - the error code is then properly propagated down to ds3000_initfe(). Signed-off-by:
Rémi Cardona <remi.cardona@smartjog.com> Reviewed-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Frank Schaefer authored
Since we have now 3 modes (auto/isoc/bulk), usb_xfer_mode is more suitable than prefer_bulk. Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
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: -
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 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:
-
