Fix various sparse warnings under drivers/media/rc/*.c, mostly
by making functions static.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The basic API of rc-core used to be:

	dev = rc_allocate_device();
	dev->x = a;
	dev->y = b;
	dev->z = c;
	rc_register_device();

which is a pretty common pattern in the kernel, after the introduction of
protocol arrays the API looks something like:

	dev = rc_allocate_device();
	dev->x = a;
	rc_set_allowed_protocols(dev, RC_BIT_X);
	dev->z = c;
	rc_register_device();

There's no real need for the protocols to be an array, so change it
back to be consistent (and in preparation for the following patches).

[m.chehab@samsung.com: added missing changes at some files]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Right now the protocol information is not preserved, rc-core gets handed a
scancode but has no idea which protocol it corresponds to.

This patch (which required reading through the source/keymap for all drivers,
not fun) makes the protocol information explicit which is important
documentation and makes it easier to e.g. support multiple protocols with one
decoder (think rc5 and rc-streamzap). The information isn't used yet so there
should be no functional changes.

[m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The allowed and enabled protocol masks need to be expanded to be per
filter type in order to support wakeup filter protocol selection. To
ease that process abstract access to the rc_dev::allowed_protos and
rc_dev::enabled_protocols members with inline functions.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Emitting an OOM message isn't necessary after input_allocate_device
as there's a generic OOM and a dump_stack already done.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Fix various spelling errors in strings and comments throughout the media
tree. The majority of these were found using Lucas De Marchi's codespell
tool.

[m.chehab@samsung.com: discard hunks with conflicts]
Signed-off-by: NJonathan McCrohan <jmccrohan@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Fix various spelling errors in strings and comments throughout the media
tree. The majority of these were found using Lucas De Marchi's codespell
tool.

[m.chehab@samsung.com: discard hunks with conflicts]
Signed-off-by: NJonathan McCrohan <jmccrohan@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This avoids:
Apr 12 23:52:16 homeserver kernel: imon:send_packet: task interrupted
Apr 12 23:52:16 homeserver kernel: ------------[ cut here ]------------
Apr 12 23:52:16 homeserver kernel: WARNING: at drivers/usb/core/urb.c:327 usb_submit_urb+0x353/0x370()
Apr 12 23:52:16 homeserver kernel: Hardware name: Unknow
Apr 12 23:52:16 homeserver kernel: URB f64b6f00 submitted while active
Apr 12 23:52:16 homeserver kernel: Modules linked in:
Apr 12 23:52:16 homeserver kernel: Pid: 3154, comm: LCDd Not tainted 3.8.6-htpc-00005-g9e6fc5e #26
Apr 12 23:52:16 homeserver kernel: Call Trace:
Apr 12 23:52:16 homeserver kernel: [<c012d778>] ? warn_slowpath_common+0x78/0xb0
Apr 12 23:52:16 homeserver kernel: [<c04136c3>] ? usb_submit_urb+0x353/0x370
Apr 12 23:52:16 homeserver kernel: [<c04136c3>] ? usb_submit_urb+0x353/0x370
Apr 12 23:52:16 homeserver kernel: [<c0447010>] ? imon_ir_change_protocol+0x150/0x150
Apr 12 23:52:16 homeserver kernel: [<c012d843>] ? warn_slowpath_fmt+0x33/0x40
Apr 12 23:52:16 homeserver kernel: [<c04136c3>] ? usb_submit_urb+0x353/0x370
Apr 12 23:52:16 homeserver kernel: [<c0446c67>] ? send_packet+0x97/0x270
Apr 12 23:52:16 homeserver kernel: [<c0446cfe>] ? send_packet+0x12e/0x270
Apr 12 23:52:16 homeserver kernel: [<c05c5743>] ? do_nanosleep+0xa3/0xd0
Apr 12 23:52:16 homeserver kernel: [<c044760e>] ? vfd_write+0xae/0x250
Apr 12 23:52:16 homeserver kernel: [<c0447560>] ? lcd_write+0x180/0x180
Apr 12 23:52:16 homeserver kernel: [<c01b2b19>] ? vfs_write+0x89/0x140
Apr 12 23:52:16 homeserver kernel: [<c01b2dda>] ? sys_write+0x4a/0x90
Apr 12 23:52:16 homeserver kernel: [<c05c7c45>] ? sysenter_do_call+0x12/0x26
Apr 12 23:52:16 homeserver kernel: ---[ end trace a0b6f0fcfd2f9a1d ]---
Apr 12 23:52:16 homeserver kernel: imon:send_packet: error submitting urb(-16)
Apr 12 23:52:16 homeserver kernel: imon:vfd_write: send packet #3 failed
Apr 12 23:52:16 homeserver kernel: imon:send_packet: error submitting urb(-16)
Apr 12 23:52:16 homeserver kernel: imon:vfd_write: send packet #0 failed
Signed-off-by: NKevin Baradon <kevin.baradon@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This bug could be triggered if 1st interface configuration fails:
Apr  8 18:20:30 homeserver kernel: usb 5-1: new low-speed USB device number 2 using ohci_hcd
Apr  8 18:20:30 homeserver kernel: input: iMON Panel, Knob and Mouse(15c2:0036) as /devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.0/input/input2
Apr  8 18:20:30 homeserver kernel: Registered IR keymap rc-imon-pad
Apr  8 18:20:30 homeserver kernel: input: iMON Remote (15c2:0036) as /devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.0/rc/rc0/input3
Apr  8 18:20:30 homeserver kernel: rc0: iMON Remote (15c2:0036) as /devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.0/rc/rc0
Apr  8 18:20:30 homeserver kernel: imon:send_packet: packet tx failed (-32)
Apr  8 18:20:30 homeserver kernel: imon 5-1:1.0: remote input dev register failed
Apr  8 18:20:30 homeserver kernel: imon 5-1:1.0: imon_init_intf0: rc device setup failed
Apr  8 18:20:30 homeserver kernel: imon 5-1:1.0: unable to initialize intf0, err 0
Apr  8 18:20:30 homeserver kernel: imon:imon_probe: failed to initialize context!
Apr  8 18:20:30 homeserver kernel: imon 5-1:1.0: unable to register, err -19
Apr  8 18:20:30 homeserver kernel: BUG: unable to handle kernel NULL pointer dereference at 00000014
Apr  8 18:20:30 homeserver kernel: IP: [<c05c4e4c>] mutex_lock+0xc/0x30
Apr  8 18:20:30 homeserver kernel: *pde = 00000000
Apr  8 18:20:30 homeserver kernel: Oops: 0002 [#1] PREEMPT SMP
Apr  8 18:20:30 homeserver kernel: Modules linked in:
Apr  8 18:20:30 homeserver kernel: Pid: 367, comm: khubd Not tainted 3.8.3-htpc-00002-g79b1403 #23 Unknow Unknow/RS780-SB700
Apr  8 18:20:30 homeserver kernel: EIP: 0060:[<c05c4e4c>] EFLAGS: 00010296 CPU: 1
Apr  8 18:20:30 homeserver kernel: EIP is at mutex_lock+0xc/0x30
Apr  8 18:20:30 homeserver kernel: EAX: 00000014 EBX: 00000014 ECX: 00000000 EDX: f590e480
Apr  8 18:20:30 homeserver kernel: ESI: f5deac00 EDI: f590e480 EBP: f5f3ee00 ESP: f6577c28
Apr  8 18:20:30 homeserver kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Apr  8 18:20:30 homeserver kernel: CR0: 8005003b CR2: 00000014 CR3: 0081b000 CR4: 000007d0
Apr  8 18:20:30 homeserver kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Apr  8 18:20:30 homeserver kernel: DR6: ffff0ff0 DR7: 00000400
Apr  8 18:20:30 homeserver kernel: Process khubd (pid: 367, ti=f6576000 task=f649ea00 task.ti=f6576000)
Apr  8 18:20:30 homeserver kernel: Stack:
Apr  8 18:20:30 homeserver kernel: 00000000 f5deac00 c0448de4 f59714c0 f5deac64 c03b8ad2 f6577c90 00000004
Apr  8 18:20:30 homeserver kernel: f649ea00 c0205142 f6779820 a1ff7f08 f5deac00 00000001 f5f3ee1c 00000014
Apr  8 18:20:30 homeserver kernel: 00000004 00000202 15c20036 c07a03e8 fffee0ca f6795c00 f5f3ee1c f5deac00
Apr  8 18:20:30 homeserver kernel: Call Trace:
Apr  8 18:20:30 homeserver kernel: [<c0448de4>] ? imon_probe+0x494/0xde0
Apr  8 18:20:30 homeserver kernel: [<c03b8ad2>] ? rpm_resume+0xb2/0x4f0
Apr  8 18:20:30 homeserver kernel: [<c0205142>] ? sysfs_addrm_finish+0x12/0x90
Apr  8 18:20:30 homeserver kernel: [<c04170e9>] ? usb_probe_interface+0x169/0x240
Apr  8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr  8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr  8 18:20:30 homeserver kernel: [<c03b0a94>] ? driver_probe_device+0x54/0x1e0
Apr  8 18:20:30 homeserver kernel: [<c0416abe>] ? usb_device_match+0x4e/0x80
Apr  8 18:20:30 homeserver kernel: [<c03af314>] ? bus_for_each_drv+0x34/0x70
Apr  8 18:20:30 homeserver kernel: [<c03b0a0b>] ? device_attach+0x7b/0x90
Apr  8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr  8 18:20:30 homeserver kernel: [<c03b00ff>] ? bus_probe_device+0x5f/0x80
Apr  8 18:20:30 homeserver kernel: [<c03aeab7>] ? device_add+0x567/0x610
Apr  8 18:20:30 homeserver kernel: [<c041a7bc>] ? usb_create_ep_devs+0x7c/0xd0
Apr  8 18:20:30 homeserver kernel: [<c0413837>] ? create_intf_ep_devs+0x47/0x70
Apr  8 18:20:30 homeserver kernel: [<c04156c4>] ? usb_set_configuration+0x454/0x750
Apr  8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr  8 18:20:30 homeserver kernel: [<c041de8a>] ? generic_probe+0x2a/0x80
Apr  8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr  8 18:20:30 homeserver kernel: [<c0205aff>] ? sysfs_create_link+0xf/0x20
Apr  8 18:20:30 homeserver kernel: [<c04171db>] ? usb_probe_device+0x1b/0x40
Apr  8 18:20:30 homeserver kernel: [<c03b0a94>] ? driver_probe_device+0x54/0x1e0
Apr  8 18:20:30 homeserver kernel: [<c03af314>] ? bus_for_each_drv+0x34/0x70
Apr  8 18:20:30 homeserver kernel: [<c03b0a0b>] ? device_attach+0x7b/0x90
Apr  8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr  8 18:20:30 homeserver kernel: [<c03b00ff>] ? bus_probe_device+0x5f/0x80
Apr  8 18:20:30 homeserver kernel: [<c03aeab7>] ? device_add+0x567/0x610
Apr  8 18:20:30 homeserver kernel: [<c040e6df>] ? usb_new_device+0x12f/0x1e0
Apr  8 18:20:30 homeserver kernel: [<c040f4d8>] ? hub_thread+0x458/0x1230
Apr  8 18:20:30 homeserver kernel: [<c015554f>] ? dequeue_task_fair+0x9f/0xc0
Apr  8 18:20:30 homeserver kernel: [<c0131312>] ? release_task+0x1d2/0x330
Apr  8 18:20:30 homeserver kernel: [<c01477b0>] ? abort_exclusive_wait+0x90/0x90
Apr  8 18:20:30 homeserver kernel: [<c040f080>] ? usb_remote_wakeup+0x40/0x40
Apr  8 18:20:30 homeserver kernel: [<c0146ed2>] ? kthread+0x92/0xa0
Apr  8 18:20:30 homeserver kernel: [<c05c7877>] ? ret_from_kernel_thread+0x1b/0x28
Apr  8 18:20:30 homeserver kernel: [<c0146e40>] ? kthread_freezable_should_stop+0x50/0x50
Apr  8 18:20:30 homeserver kernel: Code: 89 04 24 89 f0 e8 05 ff ff ff 8b 5c 24 24 8b 74 24 28 8b 7c 24 2c 8b 6c 24 30 83 c4 34 c3 00 83 ec 08 89 1c 24 89 74 24 04 89 c3 <f0> ff 08 79 05 e8 ca 03 00 00 64 a1 70 d6 80 c0 8b 74 24 04 89
Apr  8 18:20:30 homeserver kernel: EIP: [<c05c4e4c>] mutex_lock+0xc/0x30 SS:ESP 0068:f6577c28
Apr  8 18:20:30 homeserver kernel: CR2: 0000000000000014
Apr  8 18:20:30 homeserver kernel: ---[ end trace df134132c967205c ]---
Signed-off-by: NKevin Baradon <kevin.baradon@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

send_packet() is used during initialization, before send_packet_delay
is set. So, move ictx->send_packet_delay to happen earlier.

[mchehab@redhat.com: fold two patches into one to make git history clearer]
Signed-off-by: NKevin Baradon <kevin.baradon@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

My 15c2:0036 device floods syslog when a keypad key is pressed:

	Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
	Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fef2
	Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
	Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
	Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2

This patch removes those messages from imon, following suggestion from
Mauro. Unknown keys shall be correctly handled by rc/input layer.
Signed-off-by: NKevin Baradon <kevin.baradon@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some imon devices (like 15c2:0036) need a higher delay between
send_packet calls.

Default value is still 5ms to avoid regressions on already working
hardware.

Also use interruptible wait to avoid load average going too high (and
let caller handle signals).
Signed-off-by: NKevin Baradon <kevin.baradon@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Events for the iMon Knob pad where not correctly interpreted on ARM,
resulting in buggy mouse movements (cursor going straight out of the
screen), key pad only generating KEY_RIGHT and KEY_DOWN events.
A reproducer is:
int main(int argc, char ** argv)
{
        char rel_x = 0x00; printf("rel_x:%d @%s:%d\n", rel_x, __FILE__, __LINE__);
        rel_x = 0x0f; printf("rel_x:%d @%s:%d\n", rel_x, __FILE__, __LINE__);
        rel_x |= ~0x0f; printf("rel_x:%d @%s:%d\n", rel_x, __FILE__, __LINE__);
        return 0;
}
(running on x86 or amd64)
$ ./test
rel_x:0 @test.c:6
rel_x:15 @test.c:7
rel_x:-1 @test.c:8
(running on armv6)
rel_x:0 @test.c:6
rel_x:15 @test.c:7
rel_x:255 @test.c:8
Forcing the rel_x and rel_y variables as signed char fixes the issue.

Reference: http://www.arm.linux.org.uk/docs/faqs/signedchar.phpSigned-off-by: NAlexandre Lissy <alexandrelissy@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The RC_TYPE_* defines are currently used both where a single protocol is
expected and where a bitmap of protocols is expected.

Functions like rc_keydown() and functions which add/remove entries to the
keytable want a single protocol. Future userspace APIs would also
benefit from numeric protocols (rather than bitmap ones). Keytables are
smaller if they can use a small(ish) integer rather than a bitmap.

Other functions or struct members (e.g. allowed_protos,
enabled_protocols, etc) accept multiple protocols and need a bitmap.

Using different types reduces the risk of programmer error. Using a
protocol enum whereever possible also makes for a more future-proof
user-space API as we don't need to worry about a sufficient number of
bits being available (e.g. in structs used for ioctl() calls).

The use of both a number and a corresponding bit is dalso one in e.g.
the input subsystem as well (see all the references to set/clear bit when
changing keytables for example).

This patch separate the different usages in preparation for
upcoming patches.

Where a single protocol is expected, enum rc_type is used; where one or more
protocol(s) are expected, something like u64 is used.

The patch has been rewritten so that the format of the sysfs "protocols"
file is no longer altered (at the loss of some detail). The file itself
should probably be deprecated in the future though.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Cc: Andy Walls <awalls@md.metrocast.net>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Mike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Drivers that refer to a __devexit function in an operations
structure need to annotate that pointer with __devexit_p so
replace it with a NULL pointer when the section gets discarded.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NCorinna Vinschen <vinschen@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
CC: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This converts the drivers in drivers/media/* to use the
module_usb_driver() macro which makes the code smaller and a bit
simpler.

Added bonus is that it removes some unneeded kernel log messages about
drivers loading and/or unloading.

Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Luca Risolia <luca.risolia@studio.unibo.it>
Cc: Jean-Francois Moine <moinejf@free.fr>
Cc: Frank Zago <frank@zago.net>
Cc: Olivier Lorin <o.lorin@laposte.net>
Cc: Erik Andren <erik.andren@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Brian Johnson <brijohn@gmail.com>
Cc: Leandro Costantino <lcostantino@gmail.com>
Cc: Antoine Jacquet <royale@zerezo.com>
Cc: Jarod Wilson <jarod@redhat.com>
Cc: Florian Mickler <florian@mickler.org>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Michael Krufky <mkrufky@kernellabs.com>
Cc: "David Härdeman" <david@hardeman.nu>
Cc: Florent Audebert <florent.audebert@anevia.com>
Cc: Sam Doshi <sam@metal-fish.co.uk>
Cc: Manu Abraham <manu@linuxtv.org>
Cc: Olivier Grenie <olivier.grenie@dibcom.fr>
Cc: Patrick Boettcher <patrick.boettcher@dibcom.fr>
Cc: "Igor M. Liplianin" <liplianin@me.by>
Cc: Derek Kelly <user.vdr@gmail.com>
Cc: Malcolm Priestley <tvboxspy@gmail.com>
Cc: Steven Toth <stoth@kernellabs.com>
Cc: "André Weidemann" <Andre.Weidemann@web.de>
Cc: Martin Wilks <m.wilks@technisat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jose Alberto Reguero <jareguero@telefonica.net>
Cc: David Henningsson <david.henningsson@canonical.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Joe Perches <joe@perches.com>
Cc: Jesper Juhl <jj@chaosbits.net>
Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: Anssi Hannula <anssi.hannula@iki.fi>
Cc: Rafi Rubin <rafi@seas.upenn.edu>
Cc: Dan Carpenter <error27@gmail.com>
Cc: Paul Bender <pebender@gmail.com>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: "Márcio A Alves" <froooozen@gmail.com>
Cc: Julia Lawall <julia@diku.dk>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Chris Rankin <rankincj@yahoo.com>
Cc: Lee Jones <lee.jones@canonical.com>
Cc: Andy Walls <awalls@md.metrocast.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Dean Anderson <linux-dev@sensoray.com>
Cc: Pete Eberlein <pete@sensoray.com>
Cc: Arvydas Sidorenko <asido4@gmail.com>
Cc: Andrea Anacleto <andreaanacleto@libero.it>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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 <awalls@md.metrocast.net>
CC: Chris W <lkml@psychogeeks.com>
Reported-by: NChris W <lkml@psychogeeks.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NFilip Streibl <filip@streibl.cz>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Courtesy of information from Andreas Dick on the lirc list.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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/)

// <smpl>
@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)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

- 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: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The imon_ir_change_protocol function gets called two different ways, one
way is from rc_register_device, for initial protocol selection/setup,
and the other is via a userspace-initiated protocol change request,
either by direct sysfs prodding or by something like ir-keytable.

In the rc_register_device case, the imon context lock is already held,
but when initiated from userspace, it is not, so we must acquire it,
prior to calling send_packet, which requires that the lock is held.

Without this change, there's an easily reproduceable deadlock when
another function calls send_packet (such as either of the display write
fops) after a userspace-initiated change_protocol.

With a lock-debugging-enabled kernel, I was getting this:

[   15.014153] =====================================
[   15.015048] [ BUG: bad unlock balance detected! ]
[   15.015048] -------------------------------------
[   15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at:
[   15.015048] [<ffffffff814c6297>] mutex_unlock+0xe/0x10
[   15.015048] but there are no more locks to release!
[   15.015048]
[   15.015048] other info that might help us debug this:
[   15.015048] 2 locks held by ir-keytable/773:
[   15.015048]  #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff8119d400>] sysfs_write_file+0x3c/0x144
[   15.015048]  #1:  (s_active#87){.+.+.+}, at: [<ffffffff8119d4ab>] sysfs_write_file+0xe7/0x144
[   15.015048]
[   15.015048] stack backtrace:
[   15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1
[   15.015048] Call Trace:
[   15.015048]  [<ffffffff81089715>] ? print_unlock_inbalance_bug+0xca/0xd5
[   15.015048]  [<ffffffff8108b35c>] ? lock_release_non_nested+0xc1/0x263
[   15.015048]  [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[   15.015048]  [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[   15.015048]  [<ffffffff8108b67b>] ? lock_release+0x17d/0x1a4
[   15.015048]  [<ffffffff814c6229>] ? __mutex_unlock_slowpath+0xc5/0x125
[   15.015048]  [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[   15.015048]  [<ffffffffa02964b6>] ? send_packet+0x1c9/0x264 [imon]
[   15.015048]  [<ffffffff8108b376>] ? lock_release_non_nested+0xdb/0x263
[   15.015048]  [<ffffffffa0296731>] ? imon_ir_change_protocol+0x126/0x15e [imon]
[   15.015048]  [<ffffffffa024a334>] ? store_protocols+0x1c3/0x286 [rc_core]
[   15.015048]  [<ffffffff81326e4e>] ? dev_attr_store+0x20/0x22
[   15.015048]  [<ffffffff8119d4cc>] ? sysfs_write_file+0x108/0x144
...

The original report that led to the investigation was the following:

[ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds.
[ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1679.457309] LCDd            D ffff88010fcd89c8     0  8460      1 0x00000000
[ 1679.457312]  ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8
[ 1679.457314]  00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0
[ 1679.457316]  ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8
[ 1679.457319] Call Trace:
[ 1679.457324]  [<ffffffff810ff1a5>] ? zone_statistics+0x75/0x90
[ 1679.457327]  [<ffffffff810ea907>] ? get_page_from_freelist+0x3c7/0x820
[ 1679.457330]  [<ffffffff813b0a49>] __mutex_lock_slowpath+0x139/0x320
[ 1679.457335]  [<ffffffff813b0c41>] mutex_lock+0x11/0x30
[ 1679.457338]  [<ffffffffa0d54216>] display_open+0x66/0x130 [imon]
[ 1679.457345]  [<ffffffffa01d06c0>] usb_open+0x180/0x310 [usbcore]
[ 1679.457349]  [<ffffffff81143b3b>] chrdev_open+0x1bb/0x2d0
[ 1679.457350]  [<ffffffff8113d93d>] __dentry_open+0x10d/0x370
[ 1679.457352]  [<ffffffff81143980>] ? chrdev_open+0x0/0x2d0
...

Bump the driver version here so its easier to tell if people have this
locking fix or not, and also make locking during probe easier to follow.

CC: stable@kernel.org
Reported-by: NBenjamin Hodgetts <ben@xnode.org>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

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

My initial thinking was that we should default to mouse mode, so people
could use the mouse function to click on something on a login screen,
but a lot of systems where a remote is useful automatically log in a
user and launch a media center application, some of which hide the
mouse, which can be confusing to users if they punch buttons on the
remote and don't see any feedback. Plus, first and foremost, its a
remote, so lets default to being a remote, and only toggle into mouse
mode when the user explicitly asks for it. As a nice side-effect, this
actually simplifies some of the code a fair bit...
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Otherwise, we have a null receive buffer, and the logic all falls down,
goes boom, all ffdc devs wind up as imon IR w/VFD. Oops.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There's a nasty bug that slipped in when the rc device interface was
altered, only affecting the older 0xffdc imon devices. We were trying
to access ictx->rdev->allowed_protos before ictx->rdev had been set.

There's also an issue with call ordering that meant the correct
keymap wasn't getting loaded for MCE IR type 0xffdc devices.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,IR_TYPE,RC_TYPE,g <$i >a && mv a $i; done
for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_type,rc_type,g <$i >a && mv a $i; done
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Those functions are not InfraRed specific. So, rename them to properly
reflect it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The Remote Controller subsystem is meant to be used not only by Infra Red
but also for similar types of Remote Controllers. The core is not specific
to Infra Red. As such, rename:
	- ir-core.h to rc-core.h
	- IR_CORE to RC_CORE
	- namespace inside rc-core.c/rc-core.h

To be consistent with the other changes.

No functional change on this patch.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch merges the ir_input_dev and ir_dev_props structs into a single
struct called rc_dev. The drivers and various functions in rc-core used
by the drivers are also changed to use rc_dev as the primary interface
when dealing with rc-core.

This means that the input_dev is abstracted away from the drivers which
is necessary if we ever want to support multiple input devs per rc device.

The new API is similar to what the input subsystem uses, i.e:
rc_device_alloc()
rc_device_free()
rc_device_register()
rc_device_unregister()

[mchehab@redhat.com: Fix compilation on mceusb and cx231xx, due to merge conflicts]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NJarod Wilson <jarod@redhat.com>
Tested-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

This patch removes the remaining usages of the ir_input_nokey() and
ir_input_keydown() functions provided by drivers/media/IR/ir-functions.c
by using the corresponding functionality in ir-core instead.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Pointed out by Bonne Eggleston on the lirc list.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>