| Age | Commit message (Collapse) | Author |
|---|
|
The function documentation here doesn't follow kernel-doc,
as parameters aren't documented. So, stop abusing on
"/**" markups.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: "Antti Seppälä" <a.seppala@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: "David Härdeman" <david@hardeman.nu>
Cc: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Replace the specification of data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Don't populate the const arrays vfd_packet6 and fp_packet on the
stack, instead make them static. Makes the object code smaller
by over 600 bytes:
Before:
text data bss dec hex filename
43794 17920 1024 62738 f512 drivers/media/rc/imon.o
After:
text data bss dec hex filename
42994 18080 1024 62098 f292 drivers/media/rc/imon.o
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by <linux/usb.h> work with
const usb_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
RC_TYPE is confusing and it's just the protocol. So rename it.
Suggested-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sean Young <sean@mess.org>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
When an ir-spi is registered, you get this message.
rc rc0: Unspecified device as /devices/platform/soc/3f215080.spi/spi_master/spi32766/spi32766.128/rc/rc0
"Unspecified device" refers to input_name, which makes no sense for IR
TX only devices. So, rename to device_name.
Also make driver_name const char* so that no casts are needed anywhere.
Now ir-spi reports:
rc rc0: IR SPI as /devices/platform/soc/3f215080.spi/spi_master/spi32766/spi32766.128/rc/rc0
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work with const
attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
18551 2256 77 20884 5194 drivers/media/rc/imon.o
File size After adding 'const':
text data bss dec hex filename
18679 2160 77 20916 51b4 drivers/media/rc/imon.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
gcc-7 suggests that an expression using a bitwise not and a bitmask
on a 'bool' variable is better written using boolean logic:
drivers/media/rc/imon.c: In function 'imon_incoming_scancode':
drivers/media/rc/imon.c:1725:22: error: '~' on a boolean expression [-Werror=bool-operation]
ictx->pad_mouse = ~(ictx->pad_mouse) & 0x1;
^
drivers/media/rc/imon.c:1725:22: note: did you mean to use logical not?
I agree.
Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Use setup_timer() instead of init_timer() to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
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 563873318d32 ("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>
|
|
drivers/media/rc/imon.c:1343:44: warning: cast to restricted __be32
drivers/media/rc/imon.c:1343:44: warning: cast to restricted __be32
drivers/media/rc/imon.c:1343:44: warning: cast to restricted __be32
drivers/media/rc/imon.c:1343:44: warning: cast to restricted __be32
drivers/media/rc/imon.c:1343:44: warning: cast to restricted __be32
drivers/media/rc/imon.c:1343:44: warning: cast to restricted __be32
drivers/media/rc/imon.c:1407:36: warning: cast to restricted __be32
drivers/media/rc/imon.c:1407:36: warning: cast to restricted __be32
drivers/media/rc/imon.c:1407:36: warning: cast to restricted __be32
drivers/media/rc/imon.c:1407:36: warning: cast to restricted __be32
drivers/media/rc/imon.c:1407:36: warning: cast to restricted __be32
drivers/media/rc/imon.c:1407:36: warning: cast to restricted __be32
drivers/media/rc/imon.c:1512:28: warning: cast to restricted __be64
drivers/media/rc/imon.c:1512:28: warning: cast to restricted __be64
drivers/media/rc/imon.c:1512:28: warning: cast to restricted __be64
drivers/media/rc/imon.c:1512:28: warning: cast to restricted __be64
drivers/media/rc/imon.c:1512:28: warning: cast to restricted __be64
drivers/media/rc/imon.c:1512:28: warning: cast to restricted __be64
drivers/media/rc/imon.c:1512:28: warning: cast to restricted __be64
drivers/media/rc/imon.c:1512:28: warning: cast to restricted __be64
drivers/media/rc/imon.c:1512:28: warning: cast to restricted __be64
drivers/media/rc/imon.c:1512:28: warning: cast to restricted __be64
drivers/media/rc/imon.c:1516:28: warning: cast to restricted __be32
drivers/media/rc/imon.c:1516:28: warning: cast to restricted __be32
drivers/media/rc/imon.c:1516:28: warning: cast to restricted __be32
drivers/media/rc/imon.c:1516:28: warning: cast to restricted __be32
drivers/media/rc/imon.c:1516:28: warning: cast to restricted __be32
drivers/media/rc/imon.c:1516:28: warning: cast to restricted __be32
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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>
|
|
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: Kevin Baradon <kevin.baradon@gmail.com>
Signed-off-by: Mauro 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: Kevin Baradon <kevin.baradon@gmail.com>
Signed-off-by: Mauro 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: Kevin Baradon <kevin.baradon@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
keypad is pressed
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: 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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
* '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>
|
