The staging lirc_imon driver contains 4 usb ids. Two of those have a VFD
and two don't. The VFD code is exactly the same in the mainline imon
driver, so that part is easily ported.
The staging driver produces raw IR rather than scancodes for the four
devices, so I've ported the raw IR code from staging to mainline imon.
Now that mainline imon can handle these four devices, lirc_imon is no
longer needed.
Compile tested only.
Signed-off-by: Sean Young <sean@mess.org>
Cc: Venky Raju <dev@venky.ws>
Cc: Jarod Wilson <jarod@redhat.com>
Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The driver type can be assigned immediately when an RC device
requests to the framework to allocate the device.
This is an 'enum rc_driver_type' data type and specifies whether
the device is a raw receiver or scancode receiver. The type will
be given as parameter to the rc_allocate_device device.
Change accordingly all the drivers calling rc_allocate_device()
so that the device type is specified during the rc device
allocation. Whenever the device type is not specified, it will be
set as RC_DRIVER_SCANCODE which was the default '0' value.
Suggested-by: Sean Young <sean@mess.org>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Drop the FSF's postal address from the source code files that typically
contain mostly the license text. Of the 628 removed instances, 578 are
outdated.
The patch has been created with the following command without manual edits:
git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin St" -- \
drivers/media/ include/media|while read i; do i=$i perl -e '
open(F,"< $ENV{i}");
$a=join("", <F>);
$a =~ s/[ \t]*\*\n.*You should.*\n.*along with.*\n.*(\n.*USA.*$)?\n//m
&& $a =~ s/(^.*)Or, (point your browser to) /$1To obtain the license, $2\n$1/m;
close(F);
open(F, "> $ENV{i}");
print F $a;
close(F);'; done
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
There is only one waiter for the completion, therefore there is no need
to use complete_all(). Let's make that clear by using complete() instead
of complete_all().
While we are at it, we do a small optimization with the reinitialization
of the completion before we use it.
The usage pattern of the completion is:
waiter context waker context
send_packet()
init_completion()
usb_submit_urb()
wait_for_completion_interruptible()
usb_tx_callback()
complete()
imon_disonnect()
complete()
Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Due to the 80-cols restrictions, and latter due to checkpatch
warnings, several strings were broken into multiple lines. This
is not considered a good practice anymore, as it makes harder
to grep for strings at the source code.
As we're right now fixing other drivers due to KERN_CONT, we need
to be able to identify what printk strings don't end with a "\n".
It is a way easier to detect those if we don't break long lines.
So, join those continuation lines.
The patch was generated via the script below, and manually
adjusted if needed.
</script>
use Text::Tabs;
while (<>) {
if ($next ne "") {
$c=$_;
if ($c =~ /^\s+\"(.*)/) {
$c2=$1;
$next =~ s/\"\n$//;
$n = expand($next);
$funpos = index($n, '(');
$pos = index($c2, '",');
if ($funpos && $pos > 0) {
$s1 = substr $c2, 0, $pos + 2;
$s2 = ' ' x ($funpos + 1) . substr $c2, $pos + 2;
$s2 =~ s/^\s+//;
$s2 = ' ' x ($funpos + 1) . $s2 if ($s2 ne "");
print unexpand("$next$s1\n");
print unexpand("$s2\n") if ($s2 ne "");
} else {
print "$next$c2\n";
}
$next="";
next;
} else {
print $next;
}
$next="";
} else {
if (m/\"$/) {
if (!m/\\n\"$/) {
$next=$_;
next;
}
}
}
print $_;
}
</script>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Since commit 563873318d ("Merge branch 'printk-cleanups"),
continuation lines require KERN_CONT. Instead, let's just
use %*ph to print the buffer.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
kmalloc will print enough information in case of failure.
Signed-off-by: Wolfram Sang <wsa-dev@sang-engineering.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
With kernel 3.17 the imon remote control for device 15c2:0034 does not
work anymore, which uses the OTHER protocol. Only the front panel
buttons which uses the RC6 protocol are working.
Adds the missing comparison for the RC_BIT_OTHER.
Cc: stable@vger.kernel.org # for Kernel 3.17
Signed-off-by: Ulrich Eckhardt <uli@uli-eckhardt.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
imon_probe() does three usb_get_dev(), but there is no any
usb_put_dev() in the driver.
The patch adds usb_put_dev() to error paths, to imon_disconnect()
and to imon_probe() as far as usbdev is not saved anywhere.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This patch introduces the use of the function usb_endpoint_type.
The Coccinelle semantic patch that makes these changes is as follows:
@@ struct usb_endpoint_descriptor *epd; @@
- (epd->bmAttributes & \(USB_ENDPOINT_XFERTYPE_MASK\|3\))
+ usb_endpoint_type(epd)
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Make the front panel buttons working after another button on the
remote was pressed.
Signed-off-by: Ulrich Eckhardt <uli@uli-eckhardt.de>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Add the key table for the Thermaltake DH-102 to the USB-Id 15c2:0034.
Signed-off-by: Ulrich Eckhardt <uli@uli-eckhardt.de>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
This patch defines the keytables per USB Device ID.
Signed-off-by: Ulrich Eckhardt <uli@uli-eckhardt.de>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Fix various sparse warnings under drivers/media/rc/*.c, mostly
by making functions static.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro 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: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro 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: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro 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: James Hogan <james.hogan@imgtec.com>
Reviewed-by: Antti Seppälä <a.seppala@gmail.com>
Signed-off-by: Mauro 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: Joe Perches <joe@perches.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro 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: Jonathan McCrohan <jmccrohan@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.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: Kevin Baradon <kevin.baradon@gmail.com>
Signed-off-by: Mauro 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: Kevin Baradon <kevin.baradon@gmail.com>
Signed-off-by: Mauro 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.php
Signed-off-by: Alexandre Lissy <alexandrelissy@free.fr>
Signed-off-by: Mauro 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: Greg 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: David 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: Mauro 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: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] hdpvr: update picture controls to support firmware versions > 0.15
[media] wl128x: fix build errors when GPIOLIB is not enabled
[media] hdpvr: fix race conditon during start of streaming
[media] omap3isp: Fix crash caused by subdevs now having a pointer to devnodes
[media] imon: don't wedge hardware after early callbacks
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 <vinschen@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
CC: stable@vger.kernel.org
Signed-off-by: Mauro 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: Greg 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: Chris W <lkml@psychogeeks.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Filip Streibl <filip@streibl.cz>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Courtesy of information from Andreas Dick on the lirc list.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Julia Lawall <julia@diku.dk>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6:
[media] ngene: Fix CI data transfer regression Fix CI data transfer regression introduced by previous cleanup.
[media] v4l: make sure drivers supply a zeroed struct v4l2_subdev
[media] Missing frontend config for LME DM04/QQBOX
[media] rc_core: avoid kernel oops when rmmod saa7134
[media] imon: add conditional locking in change_protocol
[media] rc: show RC_TYPE_OTHER in sysfs
[media] ite-cir: modular build on ppc requires delay.h include
[media] mceusb: add Dell transceiver ID
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: Benjamin Hodgetts <ben@xnode.org>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Mauro Carvalho Chehab <mchehab@redhat.com>
