kernel.git/drivers/media/rc/imon.c, branch linux-3.2.y

media: imon: Fix null-ptr-deref in imon_probe

2017-11-26T13:51:11Z

commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream. It seems that the return value of usb_ifnum_to_if() can be NULL and needs to be checked. Signed-off-by: Arvind Yadav Tested-by: Andrey Konovalov Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings

imon: don't wedge hardware after early callbacks

2012-03-01T00:31:22Z

commit 8791d63af0cf113725ae4cb8cba9492814c59a93 upstream. This patch is just a minor update to one titled "imon: Input from ffdc device type ignored" from Corinna Vinschen. An earlier patch to prevent an oops when we got early callbacks also has the nasty side-effect of wedging imon hardware, as we don't acknowledge the urb. Rework the check slightly here to bypass processing the packet, as the driver isn't yet fully initialized, but still acknowlege the urb and submit a new rx_urb. Do this for both interfaces -- irrelevant for ffdc hardware, but relevant for newer hardware, though newer hardware doesn't spew the constant stream of data as soon as the hardware is initialized like the older ffdc devices, so they'd be less likely to trigger this anyway... Tested with both an ffdc device and an 0042 device. Reported-by: Corinna Vinschen Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

[media] imon: don't parse scancodes until intf configured

2011-09-21T17:48:15Z

The imon devices have either 1 or 2 usb interfaces on them, each wired up to its own urb callback. The interface 0 urb callback is wired up before the imon context's rc_dev pointer is filled in, which is necessary for imon 0xffdc device auto-detection to work properly, but we need to make sure we don't actually run the callback routines until we've entirely filled in the necessary bits for each given interface, lest we wind up oopsing. Technically, any imon device could have hit this, but the issue is exacerbated on the 0xffdc devices, which send a constant stream of interrupts, even when they have no valid key data. CC: Andy Walls CC: Chris W Reported-by: Chris W Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab

[media] imon: rate-limit send_packet spew

2011-08-06T13:46:45Z

There are folks with flaky imon hardware out there that doesn't always respond to requests to write to their displays for some reason, which can flood logs quickly when something like lcdproc is trying to constantly update the display, so lets rate-limit all that error spew. Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab

[media] imon: allow either proto on unknown 0xffdc

2011-07-01T19:34:01Z

While 0xffdc devices have their IR protocol hard-coded into the firmware of the device, we have no known way of telling what it is if we don't have the device's config byte already in the driver. Unknown devices default to the imon native protocol, but might actually be rc6, so we should set the driver up such that the user can load the rc6 keytable from userspace and still have a working device ahead of its config byte being added to the driver. Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab

[media] imon: auto-config ffdc 7e device

2011-07-01T19:33:38Z

Another device with the 0xffdc device id, this one with 0x7e in the config byte. Its an iMON VFD + RC6 IR, in a CoolerMaster 260 case. Reported-by: Filip Streibl Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab

[media] imon: fix initial panel key repeat suppression

2011-06-11T12:04:24Z

As pointed out on the lirc list by Andreas Dick, initial panel key repeat suppression wasn't working, as we had no timevals accumulated until after the first repeat. Also add a missing locking call. Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab

[media] imon: support for 0x46 0xffdc imon vfd

2011-06-11T12:04:16Z

Courtesy of information from Andreas Dick on the lirc list. Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab

[media] imon: Correct call to input_free_device

2011-05-20T19:34:24Z

ictx->touch is intialied in imon_init_intf1, to the result of calling the function that contains this code. Thus, in this code, input_free_device should be called on touch itself. A simplified version of the semantic match that finds this problem is: (http://coccinelle.lip6.fr/) // @r exists@ local idexpression struct input_dev * x; expression ra,rr; position p1,p2; @@ x = input_allocate_device@p1(...) ... when != x = rr when != input_free_device(x,...) when != if (...) { ... input_free_device(x,...) ...} if(...) { ... when != x = ra when forall when != input_free_device(x,...) \(return <+...x...+>; \| return@p2...; \) } @script:python@ p1 << r.p1; p2 << r.p2; @@ cocci.print_main("input_allocate_device",p1) cocci.print_secs("input_free_device",p2) // Signed-off-by: Julia Lawall Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab

[media] imon: clean up disconnect routine

2011-05-20T18:56:41Z

- Eliminate a possible circular locking lockdep warning - Make sure we don't try to unregister a vfd on a device w/a vga screen - Always free imon context after devices are removed (display_close can just error out w/no context) Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab