1
0
Fork 0
alistair23-linux/drivers/media/rc/rc-main.c

2036 lines
52 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0
// rc-main.c - Remote Controller core module
//
// Copyright (C) 2009-2010 by Mauro Carvalho Chehab
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <media/rc-core.h>
#include <linux/bsearch.h>
#include <linux/spinlock.h>
#include <linux/delay.h>
#include <linux/input.h>
#include <linux/leds.h>
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 02:04:11 -06:00
#include <linux/slab.h>
#include <linux/idr.h>
#include <linux/device.h>
#include <linux/module.h>
#include "rc-core-priv.h"
/* Sizes are in bytes, 256 bytes allows for 32 entries on x64 */
#define IR_TAB_MIN_SIZE 256
#define IR_TAB_MAX_SIZE 8192
static const struct {
const char *name;
unsigned int repeat_period;
unsigned int scancode_bits;
} protocols[] = {
[RC_PROTO_UNKNOWN] = { .name = "unknown", .repeat_period = 125 },
[RC_PROTO_OTHER] = { .name = "other", .repeat_period = 125 },
[RC_PROTO_RC5] = { .name = "rc-5",
.scancode_bits = 0x1f7f, .repeat_period = 114 },
[RC_PROTO_RC5X_20] = { .name = "rc-5x-20",
.scancode_bits = 0x1f7f3f, .repeat_period = 114 },
[RC_PROTO_RC5_SZ] = { .name = "rc-5-sz",
.scancode_bits = 0x2fff, .repeat_period = 114 },
[RC_PROTO_JVC] = { .name = "jvc",
.scancode_bits = 0xffff, .repeat_period = 125 },
[RC_PROTO_SONY12] = { .name = "sony-12",
.scancode_bits = 0x1f007f, .repeat_period = 100 },
[RC_PROTO_SONY15] = { .name = "sony-15",
.scancode_bits = 0xff007f, .repeat_period = 100 },
[RC_PROTO_SONY20] = { .name = "sony-20",
.scancode_bits = 0x1fff7f, .repeat_period = 100 },
[RC_PROTO_NEC] = { .name = "nec",
.scancode_bits = 0xffff, .repeat_period = 110 },
[RC_PROTO_NECX] = { .name = "nec-x",
.scancode_bits = 0xffffff, .repeat_period = 110 },
[RC_PROTO_NEC32] = { .name = "nec-32",
.scancode_bits = 0xffffffff, .repeat_period = 110 },
[RC_PROTO_SANYO] = { .name = "sanyo",
.scancode_bits = 0x1fffff, .repeat_period = 125 },
[RC_PROTO_MCIR2_KBD] = { .name = "mcir2-kbd",
.scancode_bits = 0xffffff, .repeat_period = 100 },
[RC_PROTO_MCIR2_MSE] = { .name = "mcir2-mse",
.scancode_bits = 0x1fffff, .repeat_period = 100 },
[RC_PROTO_RC6_0] = { .name = "rc-6-0",
.scancode_bits = 0xffff, .repeat_period = 114 },
[RC_PROTO_RC6_6A_20] = { .name = "rc-6-6a-20",
.scancode_bits = 0xfffff, .repeat_period = 114 },
[RC_PROTO_RC6_6A_24] = { .name = "rc-6-6a-24",
.scancode_bits = 0xffffff, .repeat_period = 114 },
[RC_PROTO_RC6_6A_32] = { .name = "rc-6-6a-32",
.scancode_bits = 0xffffffff, .repeat_period = 114 },
[RC_PROTO_RC6_MCE] = { .name = "rc-6-mce",
.scancode_bits = 0xffff7fff, .repeat_period = 114 },
[RC_PROTO_SHARP] = { .name = "sharp",
.scancode_bits = 0x1fff, .repeat_period = 125 },
[RC_PROTO_XMP] = { .name = "xmp", .repeat_period = 125 },
[RC_PROTO_CEC] = { .name = "cec", .repeat_period = 0 },
[RC_PROTO_IMON] = { .name = "imon",
.scancode_bits = 0x7fffffff, .repeat_period = 114 },
[RC_PROTO_RCMM12] = { .name = "rc-mm-12",
.scancode_bits = 0x00000fff, .repeat_period = 114 },
[RC_PROTO_RCMM24] = { .name = "rc-mm-24",
.scancode_bits = 0x00ffffff, .repeat_period = 114 },
[RC_PROTO_RCMM32] = { .name = "rc-mm-32",
.scancode_bits = 0xffffffff, .repeat_period = 114 },
media: rc: xbox_remote: add protocol and set timeout The timestamps in ir-keytable -t output showed that the Xbox DVD IR dongle decodes scancodes every 64ms. The last scancode of a longer button press is decodes 64ms after the last-but-one which indicates the decoder doesn't use a timeout but decodes on the last edge of the signal. 267.042629: lirc protocol(unknown): scancode = 0xace 267.042665: event type EV_MSC(0x04): scancode = 0xace 267.042665: event type EV_KEY(0x01) key_down: KEY_1(0x0002) 267.042665: event type EV_SYN(0x00). 267.106625: lirc protocol(unknown): scancode = 0xace 267.106643: event type EV_MSC(0x04): scancode = 0xace 267.106643: event type EV_SYN(0x00). 267.170623: lirc protocol(unknown): scancode = 0xace 267.170638: event type EV_MSC(0x04): scancode = 0xace 267.170638: event type EV_SYN(0x00). 267.234621: lirc protocol(unknown): scancode = 0xace 267.234636: event type EV_MSC(0x04): scancode = 0xace 267.234636: event type EV_SYN(0x00). 267.298623: lirc protocol(unknown): scancode = 0xace 267.298638: event type EV_MSC(0x04): scancode = 0xace 267.298638: event type EV_SYN(0x00). 267.543345: event type EV_KEY(0x01) key_down: KEY_1(0x0002) 267.543345: event type EV_SYN(0x00). 267.570015: event type EV_KEY(0x01) key_up: KEY_1(0x0002) 267.570015: event type EV_SYN(0x00). Add a protocol with the repeat value and set the timeout in the driver to 10ms (to have a bit of headroom for delays) so the Xbox DVD remote performs more responsive. Signed-off-by: Matthias Reichl <hias@horus.com> Acked-by: Benjamin Valentin <benpicco@googlemail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-03-24 03:43:51 -06:00
[RC_PROTO_XBOX_DVD] = { .name = "xbox-dvd", .repeat_period = 64 },
};
/* Used to keep track of known keymaps */
static LIST_HEAD(rc_map_list);
static DEFINE_SPINLOCK(rc_map_lock);
static struct led_trigger *led_feedback;
/* Used to keep track of rc devices */
static DEFINE_IDA(rc_ida);
static struct rc_map_list *seek_rc_map(const char *name)
{
struct rc_map_list *map = NULL;
spin_lock(&rc_map_lock);
list_for_each_entry(map, &rc_map_list, list) {
if (!strcmp(name, map->map.name)) {
spin_unlock(&rc_map_lock);
return map;
}
}
spin_unlock(&rc_map_lock);
return NULL;
}
struct rc_map *rc_map_get(const char *name)
{
struct rc_map_list *map;
map = seek_rc_map(name);
#ifdef CONFIG_MODULES
if (!map) {
int rc = request_module("%s", name);
if (rc < 0) {
pr_err("Couldn't load IR keymap %s\n", name);
return NULL;
}
msleep(20); /* Give some time for IR to register */
map = seek_rc_map(name);
}
#endif
if (!map) {
pr_err("IR keymap %s not found\n", name);
return NULL;
}
printk(KERN_INFO "Registered IR keymap %s\n", map->map.name);
return &map->map;
}
EXPORT_SYMBOL_GPL(rc_map_get);
int rc_map_register(struct rc_map_list *map)
{
spin_lock(&rc_map_lock);
list_add_tail(&map->list, &rc_map_list);
spin_unlock(&rc_map_lock);
return 0;
}
EXPORT_SYMBOL_GPL(rc_map_register);
void rc_map_unregister(struct rc_map_list *map)
{
spin_lock(&rc_map_lock);
list_del(&map->list);
spin_unlock(&rc_map_lock);
}
EXPORT_SYMBOL_GPL(rc_map_unregister);
static struct rc_map_table empty[] = {
{ 0x2a, KEY_COFFEE },
};
static struct rc_map_list empty_map = {
.map = {
.scan = empty,
.size = ARRAY_SIZE(empty),
.rc_proto = RC_PROTO_UNKNOWN, /* Legacy IR type */
.name = RC_MAP_EMPTY,
}
};
/**
* ir_create_table() - initializes a scancode table
* @dev: the rc_dev device
* @rc_map: the rc_map to initialize
* @name: name to assign to the table
* @rc_proto: ir type to assign to the new table
* @size: initial size of the table
*
* This routine will initialize the rc_map and will allocate
* memory to hold at least the specified number of elements.
*
* return: zero on success or a negative error code
*/
static int ir_create_table(struct rc_dev *dev, struct rc_map *rc_map,
const char *name, u64 rc_proto, size_t size)
{
rc_map->name = kstrdup(name, GFP_KERNEL);
if (!rc_map->name)
return -ENOMEM;
rc_map->rc_proto = rc_proto;
rc_map->alloc = roundup_pow_of_two(size * sizeof(struct rc_map_table));
rc_map->size = rc_map->alloc / sizeof(struct rc_map_table);
rc_map->scan = kmalloc(rc_map->alloc, GFP_KERNEL);
if (!rc_map->scan) {
kfree(rc_map->name);
rc_map->name = NULL;
return -ENOMEM;
}
dev_dbg(&dev->dev, "Allocated space for %u keycode entries (%u bytes)\n",
rc_map->size, rc_map->alloc);
return 0;
}
/**
* ir_free_table() - frees memory allocated by a scancode table
* @rc_map: the table whose mappings need to be freed
*
* This routine will free memory alloctaed for key mappings used by given
* scancode table.
*/
static void ir_free_table(struct rc_map *rc_map)
{
rc_map->size = 0;
kfree(rc_map->name);
[media] rc-main: clear rc_map.name in ir_free_table() rc_unregister_device() will first call ir_free_table(), and later device_del(); however, the latter causes a call to rc_dev_uevent(), which prints rc_map.name, which at this point has already bee freed. This fixes a use-after-free bug found with KASAN. As reported by Shuah: "I am seeing the following when I do rmmod on au0828 BUG: KASAN: use-after-free in string+0x170/0x1f0 at addr ffff8801bd513000 Read of size 1 by task rmmod/1831 CPU: 1 PID: 1831 Comm: rmmod Tainted: G W 4.9.0-rc5 #5 Hardware name: Hewlett-Packard HP ProBook 6475b/180F, BIOS 68TTU Ver. F.04 08/03/2012 ffff8801aea2f680 ffffffff81b37ad3 ffff8801fa403b80 ffff8801bd513000 ffff8801aea2f6a8 ffffffff8156c301 ffff8801aea2f738 ffff8801bd513000 ffff8801fa403b80 ffff8801aea2f728 ffffffff8156c59a ffff8801aea2f770 Call Trace: dump_stack+0x67/0x94 [<ffffffff8156c301>] kasan_object_err+0x21/0x70 [<ffffffff8156c59a>] kasan_report_error+0x1fa/0x4d0 [<ffffffffa116f05f>] ? au0828_exit+0x10/0x21 [au0828] [<ffffffff8156c8b3>] __asan_report_load1_noabort+0x43/0x50 [<ffffffff81b58b20>] ? string+0x170/0x1f0 [<ffffffff81b58b20>] string+0x170/0x1f0 [<ffffffff81b621c4>] vsnprintf+0x374/0x1c50 [<ffffffff81b61e50>] ? pointer+0xa80/0xa80 [<ffffffff8156b676>] ? save_stack+0x46/0xd0 [<ffffffff81566faa>] ? __kmalloc+0x14a/0x2a0 [<ffffffff81b3d70a>] ? kobject_get_path+0x9a/0x200 [<ffffffff81b408c2>] ? kobject_uevent_env+0x282/0xca0 [<ffffffff81b412eb>] ? kobject_uevent+0xb/0x10 [<ffffffff81f10104>] ? device_del+0x434/0x6d0 [<ffffffffa0fea717>] ? rc_unregister_device+0x177/0x240 [rc_core] [<ffffffffa116eeb0>] ? au0828_rc_unregister+0x60/0xb0 [au0828] The problem is fixed with this patch on Linux 4.9-rc4" Signed-off-by: Max Kellermann <max.kellermann@gmail.com> Tested-by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-08-09 15:32:06 -06:00
rc_map->name = NULL;
kfree(rc_map->scan);
rc_map->scan = NULL;
}
/**
* ir_resize_table() - resizes a scancode table if necessary
* @dev: the rc_dev device
* @rc_map: the rc_map to resize
* @gfp_flags: gfp flags to use when allocating memory
*
* This routine will shrink the rc_map if it has lots of
* unused entries and grow it if it is full.
*
* return: zero on success or a negative error code
*/
static int ir_resize_table(struct rc_dev *dev, struct rc_map *rc_map,
gfp_t gfp_flags)
{
unsigned int oldalloc = rc_map->alloc;
unsigned int newalloc = oldalloc;
struct rc_map_table *oldscan = rc_map->scan;
struct rc_map_table *newscan;
if (rc_map->size == rc_map->len) {
/* All entries in use -> grow keytable */
if (rc_map->alloc >= IR_TAB_MAX_SIZE)
return -ENOMEM;
newalloc *= 2;
dev_dbg(&dev->dev, "Growing table to %u bytes\n", newalloc);
}
if ((rc_map->len * 3 < rc_map->size) && (oldalloc > IR_TAB_MIN_SIZE)) {
/* Less than 1/3 of entries in use -> shrink keytable */
newalloc /= 2;
dev_dbg(&dev->dev, "Shrinking table to %u bytes\n", newalloc);
}
if (newalloc == oldalloc)
return 0;
newscan = kmalloc(newalloc, gfp_flags);
if (!newscan)
return -ENOMEM;
memcpy(newscan, rc_map->scan, rc_map->len * sizeof(struct rc_map_table));
rc_map->scan = newscan;
rc_map->alloc = newalloc;
rc_map->size = rc_map->alloc / sizeof(struct rc_map_table);
kfree(oldscan);
return 0;
}
/**
* ir_update_mapping() - set a keycode in the scancode->keycode table
* @dev: the struct rc_dev device descriptor
* @rc_map: scancode table to be adjusted
* @index: index of the mapping that needs to be updated
* @new_keycode: the desired keycode
*
* This routine is used to update scancode->keycode mapping at given
* position.
*
* return: previous keycode assigned to the mapping
*
*/
static unsigned int ir_update_mapping(struct rc_dev *dev,
struct rc_map *rc_map,
unsigned int index,
unsigned int new_keycode)
{
int old_keycode = rc_map->scan[index].keycode;
int i;
/* Did the user wish to remove the mapping? */
if (new_keycode == KEY_RESERVED || new_keycode == KEY_UNKNOWN) {
dev_dbg(&dev->dev, "#%d: Deleting scan 0x%04x\n",
index, rc_map->scan[index].scancode);
rc_map->len--;
memmove(&rc_map->scan[index], &rc_map->scan[index+ 1],
(rc_map->len - index) * sizeof(struct rc_map_table));
} else {
dev_dbg(&dev->dev, "#%d: %s scan 0x%04x with key 0x%04x\n",
index,
old_keycode == KEY_RESERVED ? "New" : "Replacing",
rc_map->scan[index].scancode, new_keycode);
rc_map->scan[index].keycode = new_keycode;
__set_bit(new_keycode, dev->input_dev->keybit);
}
if (old_keycode != KEY_RESERVED) {
/* A previous mapping was updated... */
__clear_bit(old_keycode, dev->input_dev->keybit);
/* ... but another scancode might use the same keycode */
for (i = 0; i < rc_map->len; i++) {
if (rc_map->scan[i].keycode == old_keycode) {
__set_bit(old_keycode, dev->input_dev->keybit);
break;
}
}
/* Possibly shrink the keytable, failure is not a problem */
ir_resize_table(dev, rc_map, GFP_ATOMIC);
}
return old_keycode;
}
/**
* ir_establish_scancode() - set a keycode in the scancode->keycode table
* @dev: the struct rc_dev device descriptor
* @rc_map: scancode table to be searched
* @scancode: the desired scancode
* @resize: controls whether we allowed to resize the table to
* accommodate not yet present scancodes
*
* This routine is used to locate given scancode in rc_map.
* If scancode is not yet present the routine will allocate a new slot
* for it.
*
* return: index of the mapping containing scancode in question
* or -1U in case of failure.
*/
static unsigned int ir_establish_scancode(struct rc_dev *dev,
struct rc_map *rc_map,
unsigned int scancode,
bool resize)
{
unsigned int i;
/*
* Unfortunately, some hardware-based IR decoders don't provide
* all bits for the complete IR code. In general, they provide only
* the command part of the IR code. Yet, as it is possible to replace
* the provided IR with another one, it is needed to allow loading
* IR tables from other remotes. So, we support specifying a mask to
* indicate the valid bits of the scancodes.
*/
if (dev->scancode_mask)
scancode &= dev->scancode_mask;
/* First check if we already have a mapping for this ir command */
for (i = 0; i < rc_map->len; i++) {
if (rc_map->scan[i].scancode == scancode)
return i;
/* Keytable is sorted from lowest to highest scancode */
if (rc_map->scan[i].scancode >= scancode)
break;
}
/* No previous mapping found, we might need to grow the table */
if (rc_map->size == rc_map->len) {
if (!resize || ir_resize_table(dev, rc_map, GFP_ATOMIC))
return -1U;
}
/* i is the proper index to insert our new keycode */
if (i < rc_map->len)
memmove(&rc_map->scan[i + 1], &rc_map->scan[i],
(rc_map->len - i) * sizeof(struct rc_map_table));
rc_map->scan[i].scancode = scancode;
rc_map->scan[i].keycode = KEY_RESERVED;
rc_map->len++;
return i;
}
/**
* ir_setkeycode() - set a keycode in the scancode->keycode table
* @idev: the struct input_dev device descriptor
* @ke: Input keymap entry
* @old_keycode: result
*
* This routine is used to handle evdev EVIOCSKEY ioctl.
*
* return: -EINVAL if the keycode could not be inserted, otherwise zero.
*/
static int ir_setkeycode(struct input_dev *idev,
const struct input_keymap_entry *ke,
unsigned int *old_keycode)
{
struct rc_dev *rdev = input_get_drvdata(idev);
struct rc_map *rc_map = &rdev->rc_map;
unsigned int index;
unsigned int scancode;
int retval = 0;
unsigned long flags;
spin_lock_irqsave(&rc_map->lock, flags);
if (ke->flags & INPUT_KEYMAP_BY_INDEX) {
index = ke->index;
if (index >= rc_map->len) {
retval = -EINVAL;
goto out;
}
} else {
retval = input_scancode_to_scalar(ke, &scancode);
if (retval)
goto out;
index = ir_establish_scancode(rdev, rc_map, scancode, true);
if (index >= rc_map->len) {
retval = -ENOMEM;
goto out;
}
}
*old_keycode = ir_update_mapping(rdev, rc_map, index, ke->keycode);
out:
spin_unlock_irqrestore(&rc_map->lock, flags);
return retval;
}
/**
* ir_setkeytable() - sets several entries in the scancode->keycode table
* @dev: the struct rc_dev device descriptor
* @from: the struct rc_map to copy entries from
*
* This routine is used to handle table initialization.
*
* return: -ENOMEM if all keycodes could not be inserted, otherwise zero.
*/
static int ir_setkeytable(struct rc_dev *dev,
const struct rc_map *from)
{
struct rc_map *rc_map = &dev->rc_map;
unsigned int i, index;
int rc;
rc = ir_create_table(dev, rc_map, from->name, from->rc_proto,
from->size);
if (rc)
return rc;
for (i = 0; i < from->size; i++) {
index = ir_establish_scancode(dev, rc_map,
from->scan[i].scancode, false);
if (index >= rc_map->len) {
rc = -ENOMEM;
break;
}
ir_update_mapping(dev, rc_map, index,
from->scan[i].keycode);
}
if (rc)
ir_free_table(rc_map);
return rc;
}
static int rc_map_cmp(const void *key, const void *elt)
{
const unsigned int *scancode = key;
const struct rc_map_table *e = elt;
if (*scancode < e->scancode)
return -1;
else if (*scancode > e->scancode)
return 1;
return 0;
}
/**
* ir_lookup_by_scancode() - locate mapping by scancode
* @rc_map: the struct rc_map to search
* @scancode: scancode to look for in the table
*
* This routine performs binary search in RC keykeymap table for
* given scancode.
*
* return: index in the table, -1U if not found
*/
static unsigned int ir_lookup_by_scancode(const struct rc_map *rc_map,
unsigned int scancode)
{
struct rc_map_table *res;
res = bsearch(&scancode, rc_map->scan, rc_map->len,
sizeof(struct rc_map_table), rc_map_cmp);
if (!res)
return -1U;
else
return res - rc_map->scan;
}
/**
* ir_getkeycode() - get a keycode from the scancode->keycode table
* @idev: the struct input_dev device descriptor
* @ke: Input keymap entry
*
* This routine is used to handle evdev EVIOCGKEY ioctl.
*
* return: always returns zero.
*/
static int ir_getkeycode(struct input_dev *idev,
struct input_keymap_entry *ke)
{
struct rc_dev *rdev = input_get_drvdata(idev);
struct rc_map *rc_map = &rdev->rc_map;
struct rc_map_table *entry;
unsigned long flags;
unsigned int index;
unsigned int scancode;
int retval;
spin_lock_irqsave(&rc_map->lock, flags);
if (ke->flags & INPUT_KEYMAP_BY_INDEX) {
index = ke->index;
} else {
retval = input_scancode_to_scalar(ke, &scancode);
if (retval)
goto out;
index = ir_lookup_by_scancode(rc_map, scancode);
}
if (index < rc_map->len) {
entry = &rc_map->scan[index];
ke->index = index;
ke->keycode = entry->keycode;
ke->len = sizeof(entry->scancode);
memcpy(ke->scancode, &entry->scancode, sizeof(entry->scancode));
} else if (!(ke->flags & INPUT_KEYMAP_BY_INDEX)) {
/*
* We do not really know the valid range of scancodes
* so let's respond with KEY_RESERVED to anything we
* do not have mapping for [yet].
*/
ke->index = index;
ke->keycode = KEY_RESERVED;
} else {
retval = -EINVAL;
goto out;
}
retval = 0;
out:
spin_unlock_irqrestore(&rc_map->lock, flags);
return retval;
}
/**
* rc_g_keycode_from_table() - gets the keycode that corresponds to a scancode
* @dev: the struct rc_dev descriptor of the device
* @scancode: the scancode to look for
*
* This routine is used by drivers which need to convert a scancode to a
* keycode. Normally it should not be used since drivers should have no
* interest in keycodes.
*
* return: the corresponding keycode, or KEY_RESERVED
*/
u32 rc_g_keycode_from_table(struct rc_dev *dev, u32 scancode)
{
struct rc_map *rc_map = &dev->rc_map;
unsigned int keycode;
unsigned int index;
unsigned long flags;
spin_lock_irqsave(&rc_map->lock, flags);
index = ir_lookup_by_scancode(rc_map, scancode);
keycode = index < rc_map->len ?
rc_map->scan[index].keycode : KEY_RESERVED;
spin_unlock_irqrestore(&rc_map->lock, flags);
if (keycode != KEY_RESERVED)
dev_dbg(&dev->dev, "%s: scancode 0x%04x keycode 0x%02x\n",
dev->device_name, scancode, keycode);
return keycode;
}
EXPORT_SYMBOL_GPL(rc_g_keycode_from_table);
/**
* ir_do_keyup() - internal function to signal the release of a keypress
* @dev: the struct rc_dev descriptor of the device
[media] rc: call input_sync after scancode reports Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: Stephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-23 07:40:55 -06:00
* @sync: whether or not to call input_sync
*
* This function is used internally to release a keypress, it must be
* called with keylock held.
*/
[media] rc: call input_sync after scancode reports Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: Stephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-23 07:40:55 -06:00
static void ir_do_keyup(struct rc_dev *dev, bool sync)
{
if (!dev->keypressed)
return;
dev_dbg(&dev->dev, "keyup key 0x%04x\n", dev->last_keycode);
media: rc: bang in ir_do_keyup rc_keydown() can be called from interrupt context, by e.g. an rc scancode driver. Since commit b2c96ba352b5 ("media: cec: move cec autorepeat handling to rc-core"), the del_timer_sync() call is not happy about being called in interrupt connect. del_timer() will suffice. WARNING: CPU: 0 PID: 0 at kernel/time/timer.c:1285 del_timer_sync+0x1d/0x40 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.15.0-rc1+ #1 Hardware name: /DG45ID, BIOS IDG4510H.86A.0135.2011.0225.1100 02/25/2011 task: ffffffffa3e10480 task.stack: ffffffffa3e00000 RIP: 0010:del_timer_sync+0x1d/0x40 RSP: 0018:ffff8b396bc03db0 EFLAGS: 00010046 RAX: 0000000080010000 RBX: ffff8b394d70e410 RCX: 0000000000000073 RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8b394d70e410 RBP: 0000000000000001 R08: ffffffffc0616000 R09: ffff8b396bfa3000 R10: 0000000000000000 R11: 0000000000000390 R12: ffff8b394f003800 R13: 0000000000000000 R14: ffff8b3771c19630 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b396bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1944469000 CR3: 00000001ebe09000 CR4: 00000000000006f0 Call Trace: <IRQ> ir_do_keyup.part.5+0x22/0x90 [rc_core] rc_keyup+0x37/0x50 [rc_core] usb_rx_callback_intf0+0x79/0x90 [imon] __usb_hcd_giveback_urb+0x90/0x130 uhci_giveback_urb+0xab/0x250 uhci_scan_schedule.part.34+0x806/0xb00 uhci_irq+0xab/0x150 usb_hcd_irq+0x22/0x30 __handle_irq_event_percpu+0x3a/0x180 handle_irq_event_percpu+0x30/0x70 handle_irq_event+0x27/0x50 handle_fasteoi_irq+0x6b/0x110 handle_irq+0xa5/0x100 do_IRQ+0x41/0xc0 common_interrupt+0x96/0x96 </IRQ> RIP: 0010:cpuidle_enter_state+0x9a/0x2d0 RSP: 0018:ffffffffa3e03e88 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffda RAX: ffff8b396bc1a000 RBX: 00000010da7bcd63 RCX: 00000010da7bccf6 RDX: 00000010da7bcd63 RSI: 00000010da7bcd63 RDI: 0000000000000000 RBP: ffff8b394f587400 R08: 0000000000000000 R09: 0000000000000002 R10: ffffffffa3e03e48 R11: 0000000000000390 R12: 0000000000000003 R13: ffffffffa3ebf018 R14: 0000000000000000 R15: 00000010da7ba772 ? cpuidle_enter_state+0x8d/0x2d0 do_idle+0x17b/0x1d0 cpu_startup_entry+0x6f/0x80 start_kernel+0x4a7/0x4c7 secondary_startup_64+0xa5/0xb0 Code: e7 5b 5d 41 5c e9 84 88 05 00 0f 1f 40 00 66 66 66 66 90 65 8b 05 e4 6f ef 5c a9 00 00 0f 00 53 48 89 fb 74 16 f6 47 22 20 75 10 <0f> ff 48 89 df e8 89 f1 ff ff 85 c0 79 0e f3 90 48 89 df e8 7b Fixes: b2c96ba352b5 ("media: cec: move cec autorepeat handling to rc-core") Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-12-03 06:55:24 -07:00
del_timer(&dev->timer_repeat);
input_report_key(dev->input_dev, dev->last_keycode, 0);
led_trigger_event(led_feedback, LED_OFF);
[media] rc: call input_sync after scancode reports Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: Stephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-23 07:40:55 -06:00
if (sync)
input_sync(dev->input_dev);
dev->keypressed = false;
}
/**
* rc_keyup() - signals the release of a keypress
* @dev: the struct rc_dev descriptor of the device
*
* This routine is used to signal that a key has been released on the
* remote control.
*/
void rc_keyup(struct rc_dev *dev)
{
unsigned long flags;
spin_lock_irqsave(&dev->keylock, flags);
[media] rc: call input_sync after scancode reports Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: Stephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-23 07:40:55 -06:00
ir_do_keyup(dev, true);
spin_unlock_irqrestore(&dev->keylock, flags);
}
EXPORT_SYMBOL_GPL(rc_keyup);
/**
* ir_timer_keyup() - generates a keyup event after a timeout
*
* @t: a pointer to the struct timer_list
*
* This routine will generate a keyup event some time after a keydown event
* is generated when no further activity has been detected.
*/
static void ir_timer_keyup(struct timer_list *t)
{
struct rc_dev *dev = from_timer(dev, t, timer_keyup);
unsigned long flags;
/*
* ir->keyup_jiffies is used to prevent a race condition if a
* hardware interrupt occurs at this point and the keyup timer
* event is moved further into the future as a result.
*
* The timer will then be reactivated and this function called
* again in the future. We need to exit gracefully in that case
* to allow the input subsystem to do its auto-repeat magic or
* a keyup event might follow immediately after the keydown.
*/
spin_lock_irqsave(&dev->keylock, flags);
if (time_is_before_eq_jiffies(dev->keyup_jiffies))
[media] rc: call input_sync after scancode reports Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: Stephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-23 07:40:55 -06:00
ir_do_keyup(dev, true);
spin_unlock_irqrestore(&dev->keylock, flags);
}
/**
* ir_timer_repeat() - generates a repeat event after a timeout
*
* @t: a pointer to the struct timer_list
*
* This routine will generate a soft repeat event every REP_PERIOD
* milliseconds.
*/
static void ir_timer_repeat(struct timer_list *t)
{
struct rc_dev *dev = from_timer(dev, t, timer_repeat);
struct input_dev *input = dev->input_dev;
unsigned long flags;
spin_lock_irqsave(&dev->keylock, flags);
if (dev->keypressed) {
input_event(input, EV_KEY, dev->last_keycode, 2);
input_sync(input);
if (input->rep[REP_PERIOD])
mod_timer(&dev->timer_repeat, jiffies +
msecs_to_jiffies(input->rep[REP_PERIOD]));
}
spin_unlock_irqrestore(&dev->keylock, flags);
}
static unsigned int repeat_period(int protocol)
{
if (protocol >= ARRAY_SIZE(protocols))
return 100;
return protocols[protocol].repeat_period;
}
/**
* rc_repeat() - signals that a key is still pressed
* @dev: the struct rc_dev descriptor of the device
*
* This routine is used by IR decoders when a repeat message which does
* not include the necessary bits to reproduce the scancode has been
* received.
*/
void rc_repeat(struct rc_dev *dev)
{
unsigned long flags;
unsigned int timeout = nsecs_to_jiffies(dev->timeout) +
msecs_to_jiffies(repeat_period(dev->last_protocol));
struct lirc_scancode sc = {
.scancode = dev->last_scancode, .rc_proto = dev->last_protocol,
.keycode = dev->keypressed ? dev->last_keycode : KEY_RESERVED,
.flags = LIRC_SCANCODE_FLAG_REPEAT |
(dev->last_toggle ? LIRC_SCANCODE_FLAG_TOGGLE : 0)
};
media: rc: cec devices do not have a lirc chardev This fixes an oops in ir_lirc_scancode_event(). BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 9 PID: 27687 Comm: kworker/9:2 Tainted: P           OE 4.18.12-200.fc28.x86_64 #1 Hardware name: Supermicro C7X99-OCE-F/C7X99-OCE-F, BIOS 2.1a 06/15/2018 Workqueue: events pulse8_irq_work_handler [pulse8_cec] RIP: 0010:ir_lirc_scancode_event+0x3d/0xb0 [rc_core] Code: 8d ae b4 07 00 00 49 81 c6 b8 07 00 00 53 e8 4a df c3 d5 48 89 ef 49 89 45 00 e8 4e 84 41 d6 49 8b 1e 49 89 c4 4c 39 f3 74 58 <8b> 43 38 8b 53 40 89 c1 2b 4b 3c 39 ca 72 41 21 d0 49 8b 7d 00 49 RSP: 0018:ffffaa10e3c07d58 EFLAGS: 00010017 RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000018 RDX: 0000000000000001 RSI: 00316245397fa93c RDI: ffff966d31c8d7b4 RBP: ffff966d31c8d7b4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000003 R11: ffffaa10e3c07e28 R12: 0000000000000002 R13: ffffaa10e3c07d88 R14: ffff966d31c8d7b8 R15: 0000000000000073 FS:  0000000000000000(0000) GS:ffff966d3f440000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 00000009d820a003 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  ir_do_keydown+0x75/0x260 [rc_core]  rc_keydown+0x54/0xc0 [rc_core]  cec_received_msg_ts+0xaa8/0xaf0 [cec]  process_one_work+0x1a1/0x350  worker_thread+0x30/0x380  ? pwq_unbound_release_workfn+0xd0/0xd0  kthread+0x112/0x130  ? kthread_create_worker_on_cpu+0x70/0x70  ret_from_fork+0x35/0x40 Modules linked in: rc_tt_1500 dvb_usb_dvbsky dvb_usb_v2 uas usb_storage fuse vhost_net vhost tap xt_CHECKSUM iptable_mangle ip6t_REJECT nf_reject_ipv6 tun 8021q garp mrp xt_nat macvlan xfs devlink ebta  si2157 si2168 cx25840 cx23885 kvm altera_ci tda18271 joydev ir_rc6_decoder rc_rc6_mce crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate intel_uncore altera_stapl m88ds3103 tveeprom cx2341  mxm_wmi igb crc32c_intel megaraid_sas dca i2c_algo_bit wmi vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio i2c_dev CR2: 0000000000000038 Cc: <stable@vger.kernel.org> # v4.16+ Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-10-22 03:01:50 -06:00
if (dev->allowed_protocols != RC_PROTO_BIT_CEC)
ir_lirc_scancode_event(dev, &sc);
spin_lock_irqsave(&dev->keylock, flags);
input_event(dev->input_dev, EV_MSC, MSC_SCAN, dev->last_scancode);
input_sync(dev->input_dev);
if (dev->keypressed) {
dev->keyup_jiffies = jiffies + timeout;
mod_timer(&dev->timer_keyup, dev->keyup_jiffies);
}
spin_unlock_irqrestore(&dev->keylock, flags);
}
EXPORT_SYMBOL_GPL(rc_repeat);
/**
* ir_do_keydown() - internal function to process a keypress
* @dev: the struct rc_dev descriptor of the device
* @protocol: the protocol of the keypress
* @scancode: the scancode of the keypress
* @keycode: the keycode of the keypress
* @toggle: the toggle value of the keypress
*
* This function is used internally to register a keypress, it must be
* called with keylock held.
*/
static void ir_do_keydown(struct rc_dev *dev, enum rc_proto protocol,
u32 scancode, u32 keycode, u8 toggle)
{
bool new_event = (!dev->keypressed ||
dev->last_protocol != protocol ||
dev->last_scancode != scancode ||
dev->last_toggle != toggle);
struct lirc_scancode sc = {
.scancode = scancode, .rc_proto = protocol,
.flags = toggle ? LIRC_SCANCODE_FLAG_TOGGLE : 0,
.keycode = keycode
};
media: rc: cec devices do not have a lirc chardev This fixes an oops in ir_lirc_scancode_event(). BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 9 PID: 27687 Comm: kworker/9:2 Tainted: P           OE 4.18.12-200.fc28.x86_64 #1 Hardware name: Supermicro C7X99-OCE-F/C7X99-OCE-F, BIOS 2.1a 06/15/2018 Workqueue: events pulse8_irq_work_handler [pulse8_cec] RIP: 0010:ir_lirc_scancode_event+0x3d/0xb0 [rc_core] Code: 8d ae b4 07 00 00 49 81 c6 b8 07 00 00 53 e8 4a df c3 d5 48 89 ef 49 89 45 00 e8 4e 84 41 d6 49 8b 1e 49 89 c4 4c 39 f3 74 58 <8b> 43 38 8b 53 40 89 c1 2b 4b 3c 39 ca 72 41 21 d0 49 8b 7d 00 49 RSP: 0018:ffffaa10e3c07d58 EFLAGS: 00010017 RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000018 RDX: 0000000000000001 RSI: 00316245397fa93c RDI: ffff966d31c8d7b4 RBP: ffff966d31c8d7b4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000003 R11: ffffaa10e3c07e28 R12: 0000000000000002 R13: ffffaa10e3c07d88 R14: ffff966d31c8d7b8 R15: 0000000000000073 FS:  0000000000000000(0000) GS:ffff966d3f440000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 00000009d820a003 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  ir_do_keydown+0x75/0x260 [rc_core]  rc_keydown+0x54/0xc0 [rc_core]  cec_received_msg_ts+0xaa8/0xaf0 [cec]  process_one_work+0x1a1/0x350  worker_thread+0x30/0x380  ? pwq_unbound_release_workfn+0xd0/0xd0  kthread+0x112/0x130  ? kthread_create_worker_on_cpu+0x70/0x70  ret_from_fork+0x35/0x40 Modules linked in: rc_tt_1500 dvb_usb_dvbsky dvb_usb_v2 uas usb_storage fuse vhost_net vhost tap xt_CHECKSUM iptable_mangle ip6t_REJECT nf_reject_ipv6 tun 8021q garp mrp xt_nat macvlan xfs devlink ebta  si2157 si2168 cx25840 cx23885 kvm altera_ci tda18271 joydev ir_rc6_decoder rc_rc6_mce crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate intel_uncore altera_stapl m88ds3103 tveeprom cx2341  mxm_wmi igb crc32c_intel megaraid_sas dca i2c_algo_bit wmi vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio i2c_dev CR2: 0000000000000038 Cc: <stable@vger.kernel.org> # v4.16+ Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-10-22 03:01:50 -06:00
if (dev->allowed_protocols != RC_PROTO_BIT_CEC)
ir_lirc_scancode_event(dev, &sc);
[media] rc: call input_sync after scancode reports Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: Stephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-23 07:40:55 -06:00
if (new_event && dev->keypressed)
ir_do_keyup(dev, false);
[media] rc: call input_sync after scancode reports Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: Stephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-23 07:40:55 -06:00
input_event(dev->input_dev, EV_MSC, MSC_SCAN, scancode);
dev->last_protocol = protocol;
dev->last_scancode = scancode;
dev->last_toggle = toggle;
dev->last_keycode = keycode;
[media] rc: call input_sync after scancode reports Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: Stephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-23 07:40:55 -06:00
if (new_event && keycode != KEY_RESERVED) {
/* Register a keypress */
dev->keypressed = true;
dev_dbg(&dev->dev, "%s: key down event, key 0x%04x, protocol 0x%04x, scancode 0x%08x\n",
dev->device_name, keycode, protocol, scancode);
[media] rc: call input_sync after scancode reports Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: Stephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-23 07:40:55 -06:00
input_report_key(dev->input_dev, keycode, 1);
led_trigger_event(led_feedback, LED_FULL);
[media] rc: call input_sync after scancode reports Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: Stephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-23 07:40:55 -06:00
}
/*
* For CEC, start sending repeat messages as soon as the first
* repeated message is sent, as long as REP_DELAY = 0 and REP_PERIOD
* is non-zero. Otherwise, the input layer will generate repeat
* messages.
*/
if (!new_event && keycode != KEY_RESERVED &&
dev->allowed_protocols == RC_PROTO_BIT_CEC &&
!timer_pending(&dev->timer_repeat) &&
dev->input_dev->rep[REP_PERIOD] &&
!dev->input_dev->rep[REP_DELAY]) {
input_event(dev->input_dev, EV_KEY, keycode, 2);
mod_timer(&dev->timer_repeat, jiffies +
msecs_to_jiffies(dev->input_dev->rep[REP_PERIOD]));
}
input_sync(dev->input_dev);
}
/**
* rc_keydown() - generates input event for a key press
* @dev: the struct rc_dev descriptor of the device
* @protocol: the protocol for the keypress
* @scancode: the scancode for the keypress
* @toggle: the toggle value (protocol dependent, if the protocol doesn't
* support toggle values, this should be set to zero)
*
* This routine is used to signal that a key has been pressed on the
* remote control.
*/
void rc_keydown(struct rc_dev *dev, enum rc_proto protocol, u32 scancode,
u8 toggle)
{
unsigned long flags;
u32 keycode = rc_g_keycode_from_table(dev, scancode);
spin_lock_irqsave(&dev->keylock, flags);
ir_do_keydown(dev, protocol, scancode, keycode, toggle);
if (dev->keypressed) {
dev->keyup_jiffies = jiffies + nsecs_to_jiffies(dev->timeout) +
msecs_to_jiffies(repeat_period(protocol));
mod_timer(&dev->timer_keyup, dev->keyup_jiffies);
}
spin_unlock_irqrestore(&dev->keylock, flags);
}
EXPORT_SYMBOL_GPL(rc_keydown);
/**
* rc_keydown_notimeout() - generates input event for a key press without
* an automatic keyup event at a later time
* @dev: the struct rc_dev descriptor of the device
* @protocol: the protocol for the keypress
* @scancode: the scancode for the keypress
* @toggle: the toggle value (protocol dependent, if the protocol doesn't
* support toggle values, this should be set to zero)
*
* This routine is used to signal that a key has been pressed on the
* remote control. The driver must manually call rc_keyup() at a later stage.
*/
void rc_keydown_notimeout(struct rc_dev *dev, enum rc_proto protocol,
u32 scancode, u8 toggle)
{
unsigned long flags;
u32 keycode = rc_g_keycode_from_table(dev, scancode);
spin_lock_irqsave(&dev->keylock, flags);
ir_do_keydown(dev, protocol, scancode, keycode, toggle);
spin_unlock_irqrestore(&dev->keylock, flags);
}
EXPORT_SYMBOL_GPL(rc_keydown_notimeout);
/**
* rc_validate_scancode() - checks that a scancode is valid for a protocol.
* For nec, it should do the opposite of ir_nec_bytes_to_scancode()
* @proto: protocol
* @scancode: scancode
*/
bool rc_validate_scancode(enum rc_proto proto, u32 scancode)
{
switch (proto) {
/*
* NECX has a 16-bit address; if the lower 8 bits match the upper
* 8 bits inverted, then the address would match regular nec.
*/
case RC_PROTO_NECX:
if ((((scancode >> 16) ^ ~(scancode >> 8)) & 0xff) == 0)
return false;
break;
/*
* NEC32 has a 16 bit address and 16 bit command. If the lower 8 bits
* of the command match the upper 8 bits inverted, then it would
* be either NEC or NECX.
*/
case RC_PROTO_NEC32:
if ((((scancode >> 8) ^ ~scancode) & 0xff) == 0)
return false;
break;
/*
* If the customer code (top 32-bit) is 0x800f, it is MCE else it
* is regular mode-6a 32 bit
*/
case RC_PROTO_RC6_MCE:
if ((scancode & 0xffff0000) != 0x800f0000)
return false;
break;
case RC_PROTO_RC6_6A_32:
if ((scancode & 0xffff0000) == 0x800f0000)
return false;
break;
default:
break;
}
return true;
}
/**
* rc_validate_filter() - checks that the scancode and mask are valid and
* provides sensible defaults
* @dev: the struct rc_dev descriptor of the device
* @filter: the scancode and mask
*
* return: 0 or -EINVAL if the filter is not valid
*/
static int rc_validate_filter(struct rc_dev *dev,
struct rc_scancode_filter *filter)
{
u32 mask, s = filter->data;
enum rc_proto protocol = dev->wakeup_protocol;
if (protocol >= ARRAY_SIZE(protocols))
return -EINVAL;
mask = protocols[protocol].scancode_bits;
if (!rc_validate_scancode(protocol, s))
return -EINVAL;
filter->data &= mask;
filter->mask &= mask;
/*
* If we have to raw encode the IR for wakeup, we cannot have a mask
*/
if (dev->encode_wakeup && filter->mask != 0 && filter->mask != mask)
return -EINVAL;
return 0;
}
int rc_open(struct rc_dev *rdev)
{
int rval = 0;
if (!rdev)
return -EINVAL;
mutex_lock(&rdev->lock);
[media] rc-core: don't lock device at rc_register_device() The mutex lock at rc_register_device() was added by commit 08aeb7c9a42a ("[media] rc: add locking to fix register/show race"). It is meant to avoid race issues when trying to open a sysfs file while the RC register didn't complete. Adding a lock there causes troubles, as detected by the Kernel lock debug instrumentation at the Kernel: ====================================================== [ INFO: possible circular locking dependency detected ] 4.5.0-rc3+ #46 Not tainted ------------------------------------------------------- systemd-udevd/2681 is trying to acquire lock: (s_active#171){++++.+}, at: [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0 but task is already holding lock: (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&dev->lock){+.+.+.}: [<ffffffff8124817d>] lock_acquire+0x13d/0x320 [<ffffffff822de966>] mutex_lock_nested+0xb6/0x860 [<ffffffffa0721f2b>] show_protocols+0x3b/0x3f0 [rc_core] [<ffffffff81cdaba5>] dev_attr_show+0x45/0xc0 [<ffffffff8171f1b3>] sysfs_kf_seq_show+0x203/0x3c0 [<ffffffff8171a6a1>] kernfs_seq_show+0x121/0x1b0 [<ffffffff81617c71>] seq_read+0x2f1/0x1160 [<ffffffff8171c911>] kernfs_fop_read+0x321/0x460 [<ffffffff815abc20>] __vfs_read+0xe0/0x3d0 [<ffffffff815ae90e>] vfs_read+0xde/0x2d0 [<ffffffff815b1d01>] SyS_read+0x111/0x230 [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76 -> #0 (s_active#171){++++.+}: [<ffffffff81244f24>] __lock_acquire+0x4304/0x5990 [<ffffffff8124817d>] lock_acquire+0x13d/0x320 [<ffffffff81717d3a>] __kernfs_remove+0x58a/0x810 [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0 [<ffffffff81721592>] remove_files.isra.0+0x72/0x190 [<ffffffff8172174b>] sysfs_remove_group+0x9b/0x150 [<ffffffff81721854>] sysfs_remove_groups+0x54/0xa0 [<ffffffff81cd97d0>] device_remove_attrs+0xb0/0x140 [<ffffffff81cdb27c>] device_del+0x38c/0x6b0 [<ffffffffa0724b8b>] rc_register_device+0x8cb/0x1450 [rc_core] [<ffffffffa1326a7b>] dvb_usb_remote_init+0x66b/0x14d0 [dvb_usb] [<ffffffffa1321c81>] dvb_usb_device_init+0xf21/0x1860 [dvb_usb] [<ffffffffa13517dc>] dib0700_probe+0x14c/0x410 [dvb_usb_dib0700] [<ffffffff81dbb1dd>] usb_probe_interface+0x45d/0x940 [<ffffffff81ce7e7a>] driver_probe_device+0x21a/0xc30 [<ffffffff81ce89b1>] __driver_attach+0x121/0x160 [<ffffffff81ce21bf>] bus_for_each_dev+0x11f/0x1a0 [<ffffffff81ce6cdd>] driver_attach+0x3d/0x50 [<ffffffff81ce5df9>] bus_add_driver+0x4c9/0x770 [<ffffffff81cea39c>] driver_register+0x18c/0x3b0 [<ffffffff81db6e98>] usb_register_driver+0x1f8/0x440 [<ffffffffa074001e>] dib0700_driver_init+0x1e/0x1000 [dvb_usb_dib0700] [<ffffffff810021b1>] do_one_initcall+0x141/0x300 [<ffffffff8144d8eb>] do_init_module+0x1d0/0x5ad [<ffffffff812f27b6>] load_module+0x6666/0x9ba0 [<ffffffff812f5fe8>] SyS_finit_module+0x108/0x130 [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(s_active#171); lock(&dev->lock); lock(s_active#171); *** DEADLOCK *** 3 locks held by systemd-udevd/2681: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core] In this specific case, some error happened during device init, causing IR to be disabled. Let's fix it by adding a var that will tell when the device is initialized. Any calls before that will return a -EINVAL. That should prevent the race issues. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-02-11 05:33:31 -07:00
if (!rdev->registered) {
rval = -ENODEV;
} else {
if (!rdev->users++ && rdev->open)
rval = rdev->open(rdev);
if (rval)
rdev->users--;
}
mutex_unlock(&rdev->lock);
return rval;
}
static int ir_open(struct input_dev *idev)
{
struct rc_dev *rdev = input_get_drvdata(idev);
return rc_open(rdev);
}
void rc_close(struct rc_dev *rdev)
{
if (rdev) {
mutex_lock(&rdev->lock);
if (!--rdev->users && rdev->close && rdev->registered)
rdev->close(rdev);
mutex_unlock(&rdev->lock);
}
}
static void ir_close(struct input_dev *idev)
{
struct rc_dev *rdev = input_get_drvdata(idev);
rc_close(rdev);
}
/* class for /sys/class/rc */
static char *rc_devnode(struct device *dev, umode_t *mode)
{
return kasprintf(GFP_KERNEL, "rc/%s", dev_name(dev));
}
static struct class rc_class = {
.name = "rc",
.devnode = rc_devnode,
};
[media] rc-core: add separate defines for protocol bitmaps and numbers 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>
2012-10-11 16:11:54 -06:00
/*
* These are the protocol textual descriptions that are
* used by the sysfs protocols file. Note that the order
* of the entries is relevant.
*/
static const struct {
u64 type;
const char *name;
const char *module_name;
} proto_names[] = {
{ RC_PROTO_BIT_NONE, "none", NULL },
{ RC_PROTO_BIT_OTHER, "other", NULL },
{ RC_PROTO_BIT_UNKNOWN, "unknown", NULL },
{ RC_PROTO_BIT_RC5 |
RC_PROTO_BIT_RC5X_20, "rc-5", "ir-rc5-decoder" },
{ RC_PROTO_BIT_NEC |
RC_PROTO_BIT_NECX |
RC_PROTO_BIT_NEC32, "nec", "ir-nec-decoder" },
{ RC_PROTO_BIT_RC6_0 |
RC_PROTO_BIT_RC6_6A_20 |
RC_PROTO_BIT_RC6_6A_24 |
RC_PROTO_BIT_RC6_6A_32 |
RC_PROTO_BIT_RC6_MCE, "rc-6", "ir-rc6-decoder" },
{ RC_PROTO_BIT_JVC, "jvc", "ir-jvc-decoder" },
{ RC_PROTO_BIT_SONY12 |
RC_PROTO_BIT_SONY15 |
RC_PROTO_BIT_SONY20, "sony", "ir-sony-decoder" },
{ RC_PROTO_BIT_RC5_SZ, "rc-5-sz", "ir-rc5-decoder" },
{ RC_PROTO_BIT_SANYO, "sanyo", "ir-sanyo-decoder" },
{ RC_PROTO_BIT_SHARP, "sharp", "ir-sharp-decoder" },
{ RC_PROTO_BIT_MCIR2_KBD |
RC_PROTO_BIT_MCIR2_MSE, "mce_kbd", "ir-mce_kbd-decoder" },
{ RC_PROTO_BIT_XMP, "xmp", "ir-xmp-decoder" },
{ RC_PROTO_BIT_CEC, "cec", NULL },
{ RC_PROTO_BIT_IMON, "imon", "ir-imon-decoder" },
{ RC_PROTO_BIT_RCMM12 |
RC_PROTO_BIT_RCMM24 |
RC_PROTO_BIT_RCMM32, "rc-mm", "ir-rcmm-decoder" },
media: rc: xbox_remote: add protocol and set timeout The timestamps in ir-keytable -t output showed that the Xbox DVD IR dongle decodes scancodes every 64ms. The last scancode of a longer button press is decodes 64ms after the last-but-one which indicates the decoder doesn't use a timeout but decodes on the last edge of the signal. 267.042629: lirc protocol(unknown): scancode = 0xace 267.042665: event type EV_MSC(0x04): scancode = 0xace 267.042665: event type EV_KEY(0x01) key_down: KEY_1(0x0002) 267.042665: event type EV_SYN(0x00). 267.106625: lirc protocol(unknown): scancode = 0xace 267.106643: event type EV_MSC(0x04): scancode = 0xace 267.106643: event type EV_SYN(0x00). 267.170623: lirc protocol(unknown): scancode = 0xace 267.170638: event type EV_MSC(0x04): scancode = 0xace 267.170638: event type EV_SYN(0x00). 267.234621: lirc protocol(unknown): scancode = 0xace 267.234636: event type EV_MSC(0x04): scancode = 0xace 267.234636: event type EV_SYN(0x00). 267.298623: lirc protocol(unknown): scancode = 0xace 267.298638: event type EV_MSC(0x04): scancode = 0xace 267.298638: event type EV_SYN(0x00). 267.543345: event type EV_KEY(0x01) key_down: KEY_1(0x0002) 267.543345: event type EV_SYN(0x00). 267.570015: event type EV_KEY(0x01) key_up: KEY_1(0x0002) 267.570015: event type EV_SYN(0x00). Add a protocol with the repeat value and set the timeout in the driver to 10ms (to have a bit of headroom for delays) so the Xbox DVD remote performs more responsive. Signed-off-by: Matthias Reichl <hias@horus.com> Acked-by: Benjamin Valentin <benpicco@googlemail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-03-24 03:43:51 -06:00
{ RC_PROTO_BIT_XBOX_DVD, "xbox-dvd", NULL },
};
/**
* struct rc_filter_attribute - Device attribute relating to a filter type.
* @attr: Device attribute.
* @type: Filter type.
* @mask: false for filter value, true for filter mask.
*/
struct rc_filter_attribute {
struct device_attribute attr;
enum rc_filter_type type;
bool mask;
};
#define to_rc_filter_attr(a) container_of(a, struct rc_filter_attribute, attr)
#define RC_FILTER_ATTR(_name, _mode, _show, _store, _type, _mask) \
struct rc_filter_attribute dev_attr_##_name = { \
.attr = __ATTR(_name, _mode, _show, _store), \
.type = (_type), \
.mask = (_mask), \
}
/**
* show_protocols() - shows the current IR protocol(s)
* @device: the device descriptor
* @mattr: the device attribute struct
* @buf: a pointer to the output buffer
*
* This routine is a callback routine for input read the IR protocol type(s).
* it is triggered by reading /sys/class/rc/rc?/protocols.
* It returns the protocol names of supported protocols.
* Enabled protocols are printed in brackets.
[media] rc: add locking to fix register/show race When device_add is called in rc_register_device, the rc sysfs nodes show up, and there's a window in which ir-keytable can be launched via udev and trigger a show_protocols call, which runs without various rc_dev fields filled in yet. Add some locking around registration and store/show_protocols to prevent that from happening. The problem manifests thusly: [64692.957872] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [64692.957878] IP: [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957890] PGD 19cfc7067 PUD 19cfc6067 PMD 0 [64692.957894] Oops: 0000 [#1] SMP [64692.957897] last sysfs file: /sys/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/rc/rc2/protocols [64692.957902] CPU 3 [64692.957903] Modules linked in: redrat3(+) ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_hauppauge ir_nec _decoder rc_core ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_mi di_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem pcsp kr tg3 snd_hwdep emu10k1_gp snd amd64_edac_mod gameport edac_core soundcore edac_mce_amd k8temp shpchp i2c_piix4 lm63 e100 mii uinput ipv6 raid0 rai d1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t sata_svw pata_serverworks floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: redrat3] [64692.957949] [64692.957952] Pid: 12265, comm: ir-keytable Tainted: G M W 2.6.39-rc6+ #2 empty empty/TYAN Thunder K8HM S3892 [64692.957957] RIP: 0010:[<ffffffffa036a4c1>] [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957962] RSP: 0018:ffff880194509e38 EFLAGS: 00010202 [64692.957964] RAX: 0000000000000000 RBX: ffffffffa036d1e0 RCX: ffffffffa036a47a [64692.957966] RDX: ffff88019a84d000 RSI: ffffffffa036d1e0 RDI: ffff88019cf2f3f0 [64692.957969] RBP: ffff880194509e68 R08: 0000000000000002 R09: 0000000000000000 [64692.957971] R10: 0000000000000002 R11: 0000000000001617 R12: ffff88019a84d000 [64692.957973] R13: 0000000000001000 R14: ffff8801944d2e38 R15: ffff88019ce5f190 [64692.957976] FS: 00007f0a30c9a720(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000 [64692.957979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [64692.957981] CR2: 0000000000000090 CR3: 000000019a8e0000 CR4: 00000000000006e0 [64692.957983] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [64692.957986] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [64692.957989] Process ir-keytable (pid: 12265, threadinfo ffff880194508000, task ffff88019a9fc720) [64692.957991] Stack: [64692.957992] 0000000000000002 ffffffffa036d1e0 ffff880194509f58 0000000000001000 [64692.957997] ffff8801944d2e38 ffff88019ce5f190 ffff880194509e98 ffffffff8131484b [64692.958001] ffffffff8118e923 ffffffff810e9b2f ffff880194509e98 ffff8801944d2e18 [64692.958005] Call Trace: [64692.958014] [<ffffffff8131484b>] dev_attr_show+0x27/0x4e [64692.958014] [<ffffffff8118e923>] ? sysfs_read_file+0x94/0x172 [64692.958014] [<ffffffff810e9b2f>] ? __get_free_pages+0x16/0x52 [64692.958014] [<ffffffff8118e94c>] sysfs_read_file+0xbd/0x172 [64692.958014] [<ffffffff8113205e>] vfs_read+0xac/0xf3 [64692.958014] [<ffffffff8113347b>] ? fget_light+0x3a/0xa1 [64692.958014] [<ffffffff811320f2>] sys_read+0x4d/0x74 [64692.958014] [<ffffffff814c19c2>] system_call_fastpath+0x16/0x1b Its a bit difficult to reproduce, but I'm fairly confident this has fixed the problem. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-11 12:14:31 -06:00
*
* dev->lock is taken to guard against races between
* store_protocols and show_protocols.
*/
static ssize_t show_protocols(struct device *device,
struct device_attribute *mattr, char *buf)
{
struct rc_dev *dev = to_rc_dev(device);
u64 allowed, enabled;
char *tmp = buf;
int i;
[media] rc: add locking to fix register/show race When device_add is called in rc_register_device, the rc sysfs nodes show up, and there's a window in which ir-keytable can be launched via udev and trigger a show_protocols call, which runs without various rc_dev fields filled in yet. Add some locking around registration and store/show_protocols to prevent that from happening. The problem manifests thusly: [64692.957872] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [64692.957878] IP: [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957890] PGD 19cfc7067 PUD 19cfc6067 PMD 0 [64692.957894] Oops: 0000 [#1] SMP [64692.957897] last sysfs file: /sys/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/rc/rc2/protocols [64692.957902] CPU 3 [64692.957903] Modules linked in: redrat3(+) ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_hauppauge ir_nec _decoder rc_core ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_mi di_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem pcsp kr tg3 snd_hwdep emu10k1_gp snd amd64_edac_mod gameport edac_core soundcore edac_mce_amd k8temp shpchp i2c_piix4 lm63 e100 mii uinput ipv6 raid0 rai d1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t sata_svw pata_serverworks floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: redrat3] [64692.957949] [64692.957952] Pid: 12265, comm: ir-keytable Tainted: G M W 2.6.39-rc6+ #2 empty empty/TYAN Thunder K8HM S3892 [64692.957957] RIP: 0010:[<ffffffffa036a4c1>] [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957962] RSP: 0018:ffff880194509e38 EFLAGS: 00010202 [64692.957964] RAX: 0000000000000000 RBX: ffffffffa036d1e0 RCX: ffffffffa036a47a [64692.957966] RDX: ffff88019a84d000 RSI: ffffffffa036d1e0 RDI: ffff88019cf2f3f0 [64692.957969] RBP: ffff880194509e68 R08: 0000000000000002 R09: 0000000000000000 [64692.957971] R10: 0000000000000002 R11: 0000000000001617 R12: ffff88019a84d000 [64692.957973] R13: 0000000000001000 R14: ffff8801944d2e38 R15: ffff88019ce5f190 [64692.957976] FS: 00007f0a30c9a720(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000 [64692.957979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [64692.957981] CR2: 0000000000000090 CR3: 000000019a8e0000 CR4: 00000000000006e0 [64692.957983] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [64692.957986] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [64692.957989] Process ir-keytable (pid: 12265, threadinfo ffff880194508000, task ffff88019a9fc720) [64692.957991] Stack: [64692.957992] 0000000000000002 ffffffffa036d1e0 ffff880194509f58 0000000000001000 [64692.957997] ffff8801944d2e38 ffff88019ce5f190 ffff880194509e98 ffffffff8131484b [64692.958001] ffffffff8118e923 ffffffff810e9b2f ffff880194509e98 ffff8801944d2e18 [64692.958005] Call Trace: [64692.958014] [<ffffffff8131484b>] dev_attr_show+0x27/0x4e [64692.958014] [<ffffffff8118e923>] ? sysfs_read_file+0x94/0x172 [64692.958014] [<ffffffff810e9b2f>] ? __get_free_pages+0x16/0x52 [64692.958014] [<ffffffff8118e94c>] sysfs_read_file+0xbd/0x172 [64692.958014] [<ffffffff8113205e>] vfs_read+0xac/0xf3 [64692.958014] [<ffffffff8113347b>] ? fget_light+0x3a/0xa1 [64692.958014] [<ffffffff811320f2>] sys_read+0x4d/0x74 [64692.958014] [<ffffffff814c19c2>] system_call_fastpath+0x16/0x1b Its a bit difficult to reproduce, but I'm fairly confident this has fixed the problem. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-11 12:14:31 -06:00
mutex_lock(&dev->lock);
enabled = dev->enabled_protocols;
allowed = dev->allowed_protocols;
if (dev->raw && !allowed)
allowed = ir_raw_get_allowed_protocols();
mutex_unlock(&dev->lock);
dev_dbg(&dev->dev, "%s: allowed - 0x%llx, enabled - 0x%llx\n",
__func__, (long long)allowed, (long long)enabled);
for (i = 0; i < ARRAY_SIZE(proto_names); i++) {
if (allowed & enabled & proto_names[i].type)
tmp += sprintf(tmp, "[%s] ", proto_names[i].name);
else if (allowed & proto_names[i].type)
tmp += sprintf(tmp, "%s ", proto_names[i].name);
[media] rc-core: add separate defines for protocol bitmaps and numbers 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>
2012-10-11 16:11:54 -06:00
if (allowed & proto_names[i].type)
allowed &= ~proto_names[i].type;
}
#ifdef CONFIG_LIRC
if (dev->driver_type == RC_DRIVER_IR_RAW)
tmp += sprintf(tmp, "[lirc] ");
#endif
if (tmp != buf)
tmp--;
*tmp = '\n';
[media] rc: add locking to fix register/show race When device_add is called in rc_register_device, the rc sysfs nodes show up, and there's a window in which ir-keytable can be launched via udev and trigger a show_protocols call, which runs without various rc_dev fields filled in yet. Add some locking around registration and store/show_protocols to prevent that from happening. The problem manifests thusly: [64692.957872] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [64692.957878] IP: [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957890] PGD 19cfc7067 PUD 19cfc6067 PMD 0 [64692.957894] Oops: 0000 [#1] SMP [64692.957897] last sysfs file: /sys/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/rc/rc2/protocols [64692.957902] CPU 3 [64692.957903] Modules linked in: redrat3(+) ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_hauppauge ir_nec _decoder rc_core ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_mi di_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem pcsp kr tg3 snd_hwdep emu10k1_gp snd amd64_edac_mod gameport edac_core soundcore edac_mce_amd k8temp shpchp i2c_piix4 lm63 e100 mii uinput ipv6 raid0 rai d1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t sata_svw pata_serverworks floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: redrat3] [64692.957949] [64692.957952] Pid: 12265, comm: ir-keytable Tainted: G M W 2.6.39-rc6+ #2 empty empty/TYAN Thunder K8HM S3892 [64692.957957] RIP: 0010:[<ffffffffa036a4c1>] [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957962] RSP: 0018:ffff880194509e38 EFLAGS: 00010202 [64692.957964] RAX: 0000000000000000 RBX: ffffffffa036d1e0 RCX: ffffffffa036a47a [64692.957966] RDX: ffff88019a84d000 RSI: ffffffffa036d1e0 RDI: ffff88019cf2f3f0 [64692.957969] RBP: ffff880194509e68 R08: 0000000000000002 R09: 0000000000000000 [64692.957971] R10: 0000000000000002 R11: 0000000000001617 R12: ffff88019a84d000 [64692.957973] R13: 0000000000001000 R14: ffff8801944d2e38 R15: ffff88019ce5f190 [64692.957976] FS: 00007f0a30c9a720(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000 [64692.957979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [64692.957981] CR2: 0000000000000090 CR3: 000000019a8e0000 CR4: 00000000000006e0 [64692.957983] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [64692.957986] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [64692.957989] Process ir-keytable (pid: 12265, threadinfo ffff880194508000, task ffff88019a9fc720) [64692.957991] Stack: [64692.957992] 0000000000000002 ffffffffa036d1e0 ffff880194509f58 0000000000001000 [64692.957997] ffff8801944d2e38 ffff88019ce5f190 ffff880194509e98 ffffffff8131484b [64692.958001] ffffffff8118e923 ffffffff810e9b2f ffff880194509e98 ffff8801944d2e18 [64692.958005] Call Trace: [64692.958014] [<ffffffff8131484b>] dev_attr_show+0x27/0x4e [64692.958014] [<ffffffff8118e923>] ? sysfs_read_file+0x94/0x172 [64692.958014] [<ffffffff810e9b2f>] ? __get_free_pages+0x16/0x52 [64692.958014] [<ffffffff8118e94c>] sysfs_read_file+0xbd/0x172 [64692.958014] [<ffffffff8113205e>] vfs_read+0xac/0xf3 [64692.958014] [<ffffffff8113347b>] ? fget_light+0x3a/0xa1 [64692.958014] [<ffffffff811320f2>] sys_read+0x4d/0x74 [64692.958014] [<ffffffff814c19c2>] system_call_fastpath+0x16/0x1b Its a bit difficult to reproduce, but I'm fairly confident this has fixed the problem. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-11 12:14:31 -06:00
return tmp + 1 - buf;
}
/**
* parse_protocol_change() - parses a protocol change request
* @dev: rc_dev device
* @protocols: pointer to the bitmask of current protocols
* @buf: pointer to the buffer with a list of changes
*
* Writing "+proto" will add a protocol to the protocol mask.
* Writing "-proto" will remove a protocol from protocol mask.
* Writing "proto" will enable only "proto".
* Writing "none" will disable all protocols.
* Returns the number of changes performed or a negative error code.
*/
static int parse_protocol_change(struct rc_dev *dev, u64 *protocols,
const char *buf)
{
const char *tmp;
unsigned count = 0;
bool enable, disable;
u64 mask;
int i;
while ((tmp = strsep((char **)&buf, " \n")) != NULL) {
if (!*tmp)
break;
if (*tmp == '+') {
enable = true;
disable = false;
tmp++;
} else if (*tmp == '-') {
enable = false;
disable = true;
tmp++;
} else {
enable = false;
disable = false;
}
[media] rc-core: add separate defines for protocol bitmaps and numbers 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>
2012-10-11 16:11:54 -06:00
for (i = 0; i < ARRAY_SIZE(proto_names); i++) {
if (!strcasecmp(tmp, proto_names[i].name)) {
mask = proto_names[i].type;
break;
}
}
[media] rc-core: add separate defines for protocol bitmaps and numbers 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>
2012-10-11 16:11:54 -06:00
if (i == ARRAY_SIZE(proto_names)) {
if (!strcasecmp(tmp, "lirc"))
mask = 0;
else {
dev_dbg(&dev->dev, "Unknown protocol: '%s'\n",
tmp);
return -EINVAL;
}
[media] rc-core: add separate defines for protocol bitmaps and numbers 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>
2012-10-11 16:11:54 -06:00
}
count++;
if (enable)
*protocols |= mask;
else if (disable)
*protocols &= ~mask;
else
*protocols = mask;
}
if (!count) {
dev_dbg(&dev->dev, "Protocol not specified\n");
return -EINVAL;
}
return count;
}
void ir_raw_load_modules(u64 *protocols)
{
u64 available;
int i, ret;
for (i = 0; i < ARRAY_SIZE(proto_names); i++) {
if (proto_names[i].type == RC_PROTO_BIT_NONE ||
proto_names[i].type & (RC_PROTO_BIT_OTHER |
RC_PROTO_BIT_UNKNOWN))
continue;
available = ir_raw_get_allowed_protocols();
if (!(*protocols & proto_names[i].type & ~available))
continue;
if (!proto_names[i].module_name) {
pr_err("Can't enable IR protocol %s\n",
proto_names[i].name);
*protocols &= ~proto_names[i].type;
continue;
}
ret = request_module("%s", proto_names[i].module_name);
if (ret < 0) {
pr_err("Couldn't load IR protocol module %s\n",
proto_names[i].module_name);
*protocols &= ~proto_names[i].type;
continue;
}
msleep(20);
available = ir_raw_get_allowed_protocols();
if (!(*protocols & proto_names[i].type & ~available))
continue;
pr_err("Loaded IR protocol module %s, but protocol %s still not available\n",
proto_names[i].module_name,
proto_names[i].name);
*protocols &= ~proto_names[i].type;
}
}
/**
* store_protocols() - changes the current/wakeup IR protocol(s)
* @device: the device descriptor
* @mattr: the device attribute struct
* @buf: a pointer to the input buffer
* @len: length of the input buffer
*
* This routine is for changing the IR protocol type.
* It is triggered by writing to /sys/class/rc/rc?/[wakeup_]protocols.
* See parse_protocol_change() for the valid commands.
* Returns @len on success or a negative error code.
*
* dev->lock is taken to guard against races between
* store_protocols and show_protocols.
*/
static ssize_t store_protocols(struct device *device,
struct device_attribute *mattr,
const char *buf, size_t len)
{
struct rc_dev *dev = to_rc_dev(device);
u64 *current_protocols;
struct rc_scancode_filter *filter;
u64 old_protocols, new_protocols;
ssize_t rc;
dev_dbg(&dev->dev, "Normal protocol change requested\n");
current_protocols = &dev->enabled_protocols;
filter = &dev->scancode_filter;
if (!dev->change_protocol) {
dev_dbg(&dev->dev, "Protocol switching not supported\n");
return -EINVAL;
}
mutex_lock(&dev->lock);
old_protocols = *current_protocols;
new_protocols = old_protocols;
rc = parse_protocol_change(dev, &new_protocols, buf);
if (rc < 0)
goto out;
if (dev->driver_type == RC_DRIVER_IR_RAW)
ir_raw_load_modules(&new_protocols);
rc = dev->change_protocol(dev, &new_protocols);
if (rc < 0) {
dev_dbg(&dev->dev, "Error setting protocols to 0x%llx\n",
(long long)new_protocols);
[media] rc: add locking to fix register/show race When device_add is called in rc_register_device, the rc sysfs nodes show up, and there's a window in which ir-keytable can be launched via udev and trigger a show_protocols call, which runs without various rc_dev fields filled in yet. Add some locking around registration and store/show_protocols to prevent that from happening. The problem manifests thusly: [64692.957872] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [64692.957878] IP: [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957890] PGD 19cfc7067 PUD 19cfc6067 PMD 0 [64692.957894] Oops: 0000 [#1] SMP [64692.957897] last sysfs file: /sys/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/rc/rc2/protocols [64692.957902] CPU 3 [64692.957903] Modules linked in: redrat3(+) ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_hauppauge ir_nec _decoder rc_core ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_mi di_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem pcsp kr tg3 snd_hwdep emu10k1_gp snd amd64_edac_mod gameport edac_core soundcore edac_mce_amd k8temp shpchp i2c_piix4 lm63 e100 mii uinput ipv6 raid0 rai d1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t sata_svw pata_serverworks floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: redrat3] [64692.957949] [64692.957952] Pid: 12265, comm: ir-keytable Tainted: G M W 2.6.39-rc6+ #2 empty empty/TYAN Thunder K8HM S3892 [64692.957957] RIP: 0010:[<ffffffffa036a4c1>] [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957962] RSP: 0018:ffff880194509e38 EFLAGS: 00010202 [64692.957964] RAX: 0000000000000000 RBX: ffffffffa036d1e0 RCX: ffffffffa036a47a [64692.957966] RDX: ffff88019a84d000 RSI: ffffffffa036d1e0 RDI: ffff88019cf2f3f0 [64692.957969] RBP: ffff880194509e68 R08: 0000000000000002 R09: 0000000000000000 [64692.957971] R10: 0000000000000002 R11: 0000000000001617 R12: ffff88019a84d000 [64692.957973] R13: 0000000000001000 R14: ffff8801944d2e38 R15: ffff88019ce5f190 [64692.957976] FS: 00007f0a30c9a720(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000 [64692.957979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [64692.957981] CR2: 0000000000000090 CR3: 000000019a8e0000 CR4: 00000000000006e0 [64692.957983] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [64692.957986] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [64692.957989] Process ir-keytable (pid: 12265, threadinfo ffff880194508000, task ffff88019a9fc720) [64692.957991] Stack: [64692.957992] 0000000000000002 ffffffffa036d1e0 ffff880194509f58 0000000000001000 [64692.957997] ffff8801944d2e38 ffff88019ce5f190 ffff880194509e98 ffffffff8131484b [64692.958001] ffffffff8118e923 ffffffff810e9b2f ffff880194509e98 ffff8801944d2e18 [64692.958005] Call Trace: [64692.958014] [<ffffffff8131484b>] dev_attr_show+0x27/0x4e [64692.958014] [<ffffffff8118e923>] ? sysfs_read_file+0x94/0x172 [64692.958014] [<ffffffff810e9b2f>] ? __get_free_pages+0x16/0x52 [64692.958014] [<ffffffff8118e94c>] sysfs_read_file+0xbd/0x172 [64692.958014] [<ffffffff8113205e>] vfs_read+0xac/0xf3 [64692.958014] [<ffffffff8113347b>] ? fget_light+0x3a/0xa1 [64692.958014] [<ffffffff811320f2>] sys_read+0x4d/0x74 [64692.958014] [<ffffffff814c19c2>] system_call_fastpath+0x16/0x1b Its a bit difficult to reproduce, but I'm fairly confident this has fixed the problem. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-11 12:14:31 -06:00
goto out;
}
if (new_protocols != old_protocols) {
*current_protocols = new_protocols;
dev_dbg(&dev->dev, "Protocols changed to 0x%llx\n",
(long long)new_protocols);
}
/*
* If a protocol change was attempted the filter may need updating, even
* if the actual protocol mask hasn't changed (since the driver may have
* cleared the filter).
* Try setting the same filter with the new protocol (if any).
* Fall back to clearing the filter.
*/
if (dev->s_filter && filter->mask) {
if (new_protocols)
rc = dev->s_filter(dev, filter);
else
rc = -1;
if (rc < 0) {
filter->data = 0;
filter->mask = 0;
dev->s_filter(dev, filter);
}
}
rc = len;
[media] rc: add locking to fix register/show race When device_add is called in rc_register_device, the rc sysfs nodes show up, and there's a window in which ir-keytable can be launched via udev and trigger a show_protocols call, which runs without various rc_dev fields filled in yet. Add some locking around registration and store/show_protocols to prevent that from happening. The problem manifests thusly: [64692.957872] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [64692.957878] IP: [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957890] PGD 19cfc7067 PUD 19cfc6067 PMD 0 [64692.957894] Oops: 0000 [#1] SMP [64692.957897] last sysfs file: /sys/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/rc/rc2/protocols [64692.957902] CPU 3 [64692.957903] Modules linked in: redrat3(+) ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_hauppauge ir_nec _decoder rc_core ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_mi di_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem pcsp kr tg3 snd_hwdep emu10k1_gp snd amd64_edac_mod gameport edac_core soundcore edac_mce_amd k8temp shpchp i2c_piix4 lm63 e100 mii uinput ipv6 raid0 rai d1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t sata_svw pata_serverworks floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: redrat3] [64692.957949] [64692.957952] Pid: 12265, comm: ir-keytable Tainted: G M W 2.6.39-rc6+ #2 empty empty/TYAN Thunder K8HM S3892 [64692.957957] RIP: 0010:[<ffffffffa036a4c1>] [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957962] RSP: 0018:ffff880194509e38 EFLAGS: 00010202 [64692.957964] RAX: 0000000000000000 RBX: ffffffffa036d1e0 RCX: ffffffffa036a47a [64692.957966] RDX: ffff88019a84d000 RSI: ffffffffa036d1e0 RDI: ffff88019cf2f3f0 [64692.957969] RBP: ffff880194509e68 R08: 0000000000000002 R09: 0000000000000000 [64692.957971] R10: 0000000000000002 R11: 0000000000001617 R12: ffff88019a84d000 [64692.957973] R13: 0000000000001000 R14: ffff8801944d2e38 R15: ffff88019ce5f190 [64692.957976] FS: 00007f0a30c9a720(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000 [64692.957979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [64692.957981] CR2: 0000000000000090 CR3: 000000019a8e0000 CR4: 00000000000006e0 [64692.957983] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [64692.957986] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [64692.957989] Process ir-keytable (pid: 12265, threadinfo ffff880194508000, task ffff88019a9fc720) [64692.957991] Stack: [64692.957992] 0000000000000002 ffffffffa036d1e0 ffff880194509f58 0000000000001000 [64692.957997] ffff8801944d2e38 ffff88019ce5f190 ffff880194509e98 ffffffff8131484b [64692.958001] ffffffff8118e923 ffffffff810e9b2f ffff880194509e98 ffff8801944d2e18 [64692.958005] Call Trace: [64692.958014] [<ffffffff8131484b>] dev_attr_show+0x27/0x4e [64692.958014] [<ffffffff8118e923>] ? sysfs_read_file+0x94/0x172 [64692.958014] [<ffffffff810e9b2f>] ? __get_free_pages+0x16/0x52 [64692.958014] [<ffffffff8118e94c>] sysfs_read_file+0xbd/0x172 [64692.958014] [<ffffffff8113205e>] vfs_read+0xac/0xf3 [64692.958014] [<ffffffff8113347b>] ? fget_light+0x3a/0xa1 [64692.958014] [<ffffffff811320f2>] sys_read+0x4d/0x74 [64692.958014] [<ffffffff814c19c2>] system_call_fastpath+0x16/0x1b Its a bit difficult to reproduce, but I'm fairly confident this has fixed the problem. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-11 12:14:31 -06:00
out:
mutex_unlock(&dev->lock);
return rc;
}
/**
* show_filter() - shows the current scancode filter value or mask
* @device: the device descriptor
* @attr: the device attribute struct
* @buf: a pointer to the output buffer
*
* This routine is a callback routine to read a scancode filter value or mask.
* It is triggered by reading /sys/class/rc/rc?/[wakeup_]filter[_mask].
* It prints the current scancode filter value or mask of the appropriate filter
* type in hexadecimal into @buf and returns the size of the buffer.
*
* Bits of the filter value corresponding to set bits in the filter mask are
* compared against input scancodes and non-matching scancodes are discarded.
*
* dev->lock is taken to guard against races between
* store_filter and show_filter.
*/
static ssize_t show_filter(struct device *device,
struct device_attribute *attr,
char *buf)
{
struct rc_dev *dev = to_rc_dev(device);
struct rc_filter_attribute *fattr = to_rc_filter_attr(attr);
struct rc_scancode_filter *filter;
u32 val;
[media] rc-core: don't lock device at rc_register_device() The mutex lock at rc_register_device() was added by commit 08aeb7c9a42a ("[media] rc: add locking to fix register/show race"). It is meant to avoid race issues when trying to open a sysfs file while the RC register didn't complete. Adding a lock there causes troubles, as detected by the Kernel lock debug instrumentation at the Kernel: ====================================================== [ INFO: possible circular locking dependency detected ] 4.5.0-rc3+ #46 Not tainted ------------------------------------------------------- systemd-udevd/2681 is trying to acquire lock: (s_active#171){++++.+}, at: [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0 but task is already holding lock: (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&dev->lock){+.+.+.}: [<ffffffff8124817d>] lock_acquire+0x13d/0x320 [<ffffffff822de966>] mutex_lock_nested+0xb6/0x860 [<ffffffffa0721f2b>] show_protocols+0x3b/0x3f0 [rc_core] [<ffffffff81cdaba5>] dev_attr_show+0x45/0xc0 [<ffffffff8171f1b3>] sysfs_kf_seq_show+0x203/0x3c0 [<ffffffff8171a6a1>] kernfs_seq_show+0x121/0x1b0 [<ffffffff81617c71>] seq_read+0x2f1/0x1160 [<ffffffff8171c911>] kernfs_fop_read+0x321/0x460 [<ffffffff815abc20>] __vfs_read+0xe0/0x3d0 [<ffffffff815ae90e>] vfs_read+0xde/0x2d0 [<ffffffff815b1d01>] SyS_read+0x111/0x230 [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76 -> #0 (s_active#171){++++.+}: [<ffffffff81244f24>] __lock_acquire+0x4304/0x5990 [<ffffffff8124817d>] lock_acquire+0x13d/0x320 [<ffffffff81717d3a>] __kernfs_remove+0x58a/0x810 [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0 [<ffffffff81721592>] remove_files.isra.0+0x72/0x190 [<ffffffff8172174b>] sysfs_remove_group+0x9b/0x150 [<ffffffff81721854>] sysfs_remove_groups+0x54/0xa0 [<ffffffff81cd97d0>] device_remove_attrs+0xb0/0x140 [<ffffffff81cdb27c>] device_del+0x38c/0x6b0 [<ffffffffa0724b8b>] rc_register_device+0x8cb/0x1450 [rc_core] [<ffffffffa1326a7b>] dvb_usb_remote_init+0x66b/0x14d0 [dvb_usb] [<ffffffffa1321c81>] dvb_usb_device_init+0xf21/0x1860 [dvb_usb] [<ffffffffa13517dc>] dib0700_probe+0x14c/0x410 [dvb_usb_dib0700] [<ffffffff81dbb1dd>] usb_probe_interface+0x45d/0x940 [<ffffffff81ce7e7a>] driver_probe_device+0x21a/0xc30 [<ffffffff81ce89b1>] __driver_attach+0x121/0x160 [<ffffffff81ce21bf>] bus_for_each_dev+0x11f/0x1a0 [<ffffffff81ce6cdd>] driver_attach+0x3d/0x50 [<ffffffff81ce5df9>] bus_add_driver+0x4c9/0x770 [<ffffffff81cea39c>] driver_register+0x18c/0x3b0 [<ffffffff81db6e98>] usb_register_driver+0x1f8/0x440 [<ffffffffa074001e>] dib0700_driver_init+0x1e/0x1000 [dvb_usb_dib0700] [<ffffffff810021b1>] do_one_initcall+0x141/0x300 [<ffffffff8144d8eb>] do_init_module+0x1d0/0x5ad [<ffffffff812f27b6>] load_module+0x6666/0x9ba0 [<ffffffff812f5fe8>] SyS_finit_module+0x108/0x130 [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(s_active#171); lock(&dev->lock); lock(s_active#171); *** DEADLOCK *** 3 locks held by systemd-udevd/2681: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core] In this specific case, some error happened during device init, causing IR to be disabled. Let's fix it by adding a var that will tell when the device is initialized. Any calls before that will return a -EINVAL. That should prevent the race issues. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-02-11 05:33:31 -07:00
mutex_lock(&dev->lock);
if (fattr->type == RC_FILTER_NORMAL)
filter = &dev->scancode_filter;
else
filter = &dev->scancode_wakeup_filter;
if (fattr->mask)
val = filter->mask;
else
val = filter->data;
mutex_unlock(&dev->lock);
return sprintf(buf, "%#x\n", val);
}
/**
* store_filter() - changes the scancode filter value
* @device: the device descriptor
* @attr: the device attribute struct
* @buf: a pointer to the input buffer
* @len: length of the input buffer
*
* This routine is for changing a scancode filter value or mask.
* It is triggered by writing to /sys/class/rc/rc?/[wakeup_]filter[_mask].
* Returns -EINVAL if an invalid filter value for the current protocol was
* specified or if scancode filtering is not supported by the driver, otherwise
* returns @len.
*
* Bits of the filter value corresponding to set bits in the filter mask are
* compared against input scancodes and non-matching scancodes are discarded.
*
* dev->lock is taken to guard against races between
* store_filter and show_filter.
*/
static ssize_t store_filter(struct device *device,
struct device_attribute *attr,
const char *buf, size_t len)
{
struct rc_dev *dev = to_rc_dev(device);
struct rc_filter_attribute *fattr = to_rc_filter_attr(attr);
struct rc_scancode_filter new_filter, *filter;
int ret;
unsigned long val;
int (*set_filter)(struct rc_dev *dev, struct rc_scancode_filter *filter);
ret = kstrtoul(buf, 0, &val);
if (ret < 0)
return ret;
if (fattr->type == RC_FILTER_NORMAL) {
set_filter = dev->s_filter;
filter = &dev->scancode_filter;
} else {
set_filter = dev->s_wakeup_filter;
filter = &dev->scancode_wakeup_filter;
}
if (!set_filter)
return -EINVAL;
mutex_lock(&dev->lock);
new_filter = *filter;
if (fattr->mask)
new_filter.mask = val;
else
new_filter.data = val;
if (fattr->type == RC_FILTER_WAKEUP) {
/*
* Refuse to set a filter unless a protocol is enabled
* and the filter is valid for that protocol
*/
if (dev->wakeup_protocol != RC_PROTO_UNKNOWN)
ret = rc_validate_filter(dev, &new_filter);
else
ret = -EINVAL;
if (ret != 0)
goto unlock;
}
if (fattr->type == RC_FILTER_NORMAL && !dev->enabled_protocols &&
val) {
/* refuse to set a filter unless a protocol is enabled */
ret = -EINVAL;
goto unlock;
}
ret = set_filter(dev, &new_filter);
if (ret < 0)
goto unlock;
*filter = new_filter;
unlock:
mutex_unlock(&dev->lock);
return (ret < 0) ? ret : len;
}
/**
* show_wakeup_protocols() - shows the wakeup IR protocol
* @device: the device descriptor
* @mattr: the device attribute struct
* @buf: a pointer to the output buffer
*
* This routine is a callback routine for input read the IR protocol type(s).
* it is triggered by reading /sys/class/rc/rc?/wakeup_protocols.
* It returns the protocol names of supported protocols.
* The enabled protocols are printed in brackets.
*
* dev->lock is taken to guard against races between
* store_wakeup_protocols and show_wakeup_protocols.
*/
static ssize_t show_wakeup_protocols(struct device *device,
struct device_attribute *mattr,
char *buf)
{
struct rc_dev *dev = to_rc_dev(device);
u64 allowed;
enum rc_proto enabled;
char *tmp = buf;
int i;
mutex_lock(&dev->lock);
allowed = dev->allowed_wakeup_protocols;
enabled = dev->wakeup_protocol;
mutex_unlock(&dev->lock);
dev_dbg(&dev->dev, "%s: allowed - 0x%llx, enabled - %d\n",
__func__, (long long)allowed, enabled);
for (i = 0; i < ARRAY_SIZE(protocols); i++) {
if (allowed & (1ULL << i)) {
if (i == enabled)
tmp += sprintf(tmp, "[%s] ", protocols[i].name);
else
tmp += sprintf(tmp, "%s ", protocols[i].name);
}
}
if (tmp != buf)
tmp--;
*tmp = '\n';
return tmp + 1 - buf;
}
/**
* store_wakeup_protocols() - changes the wakeup IR protocol(s)
* @device: the device descriptor
* @mattr: the device attribute struct
* @buf: a pointer to the input buffer
* @len: length of the input buffer
*
* This routine is for changing the IR protocol type.
* It is triggered by writing to /sys/class/rc/rc?/wakeup_protocols.
* Returns @len on success or a negative error code.
*
* dev->lock is taken to guard against races between
* store_wakeup_protocols and show_wakeup_protocols.
*/
static ssize_t store_wakeup_protocols(struct device *device,
struct device_attribute *mattr,
const char *buf, size_t len)
{
struct rc_dev *dev = to_rc_dev(device);
enum rc_proto protocol = RC_PROTO_UNKNOWN;
ssize_t rc;
u64 allowed;
int i;
mutex_lock(&dev->lock);
allowed = dev->allowed_wakeup_protocols;
if (!sysfs_streq(buf, "none")) {
for (i = 0; i < ARRAY_SIZE(protocols); i++) {
if ((allowed & (1ULL << i)) &&
sysfs_streq(buf, protocols[i].name)) {
protocol = i;
break;
}
}
if (i == ARRAY_SIZE(protocols)) {
rc = -EINVAL;
goto out;
}
if (dev->encode_wakeup) {
u64 mask = 1ULL << protocol;
ir_raw_load_modules(&mask);
if (!mask) {
rc = -EINVAL;
goto out;
}
}
}
if (dev->wakeup_protocol != protocol) {
dev->wakeup_protocol = protocol;
dev_dbg(&dev->dev, "Wakeup protocol changed to %d\n", protocol);
if (protocol == RC_PROTO_RC6_MCE)
dev->scancode_wakeup_filter.data = 0x800f0000;
else
dev->scancode_wakeup_filter.data = 0;
dev->scancode_wakeup_filter.mask = 0;
rc = dev->s_wakeup_filter(dev, &dev->scancode_wakeup_filter);
if (rc == 0)
rc = len;
} else {
rc = len;
}
out:
mutex_unlock(&dev->lock);
return rc;
}
static void rc_dev_release(struct device *device)
{
struct rc_dev *dev = to_rc_dev(device);
kfree(dev);
}
#define ADD_HOTPLUG_VAR(fmt, val...) \
do { \
int err = add_uevent_var(env, fmt, val); \
if (err) \
return err; \
} while (0)
static int rc_dev_uevent(struct device *device, struct kobj_uevent_env *env)
{
struct rc_dev *dev = to_rc_dev(device);
if (dev->rc_map.name)
ADD_HOTPLUG_VAR("NAME=%s", dev->rc_map.name);
if (dev->driver_name)
ADD_HOTPLUG_VAR("DRV_NAME=%s", dev->driver_name);
if (dev->device_name)
ADD_HOTPLUG_VAR("DEV_NAME=%s", dev->device_name);
return 0;
}
/*
* Static device attribute struct with the sysfs attributes for IR's
*/
static struct device_attribute dev_attr_ro_protocols =
__ATTR(protocols, 0444, show_protocols, NULL);
static struct device_attribute dev_attr_rw_protocols =
__ATTR(protocols, 0644, show_protocols, store_protocols);
static DEVICE_ATTR(wakeup_protocols, 0644, show_wakeup_protocols,
store_wakeup_protocols);
static RC_FILTER_ATTR(filter, S_IRUGO|S_IWUSR,
show_filter, store_filter, RC_FILTER_NORMAL, false);
static RC_FILTER_ATTR(filter_mask, S_IRUGO|S_IWUSR,
show_filter, store_filter, RC_FILTER_NORMAL, true);
static RC_FILTER_ATTR(wakeup_filter, S_IRUGO|S_IWUSR,
show_filter, store_filter, RC_FILTER_WAKEUP, false);
static RC_FILTER_ATTR(wakeup_filter_mask, S_IRUGO|S_IWUSR,
show_filter, store_filter, RC_FILTER_WAKEUP, true);
static struct attribute *rc_dev_rw_protocol_attrs[] = {
&dev_attr_rw_protocols.attr,
NULL,
};
static const struct attribute_group rc_dev_rw_protocol_attr_grp = {
.attrs = rc_dev_rw_protocol_attrs,
};
static struct attribute *rc_dev_ro_protocol_attrs[] = {
&dev_attr_ro_protocols.attr,
NULL,
};
static const struct attribute_group rc_dev_ro_protocol_attr_grp = {
.attrs = rc_dev_ro_protocol_attrs,
};
static struct attribute *rc_dev_filter_attrs[] = {
&dev_attr_filter.attr.attr,
&dev_attr_filter_mask.attr.attr,
NULL,
};
static const struct attribute_group rc_dev_filter_attr_grp = {
.attrs = rc_dev_filter_attrs,
};
static struct attribute *rc_dev_wakeup_filter_attrs[] = {
&dev_attr_wakeup_filter.attr.attr,
&dev_attr_wakeup_filter_mask.attr.attr,
&dev_attr_wakeup_protocols.attr,
NULL,
};
static const struct attribute_group rc_dev_wakeup_filter_attr_grp = {
.attrs = rc_dev_wakeup_filter_attrs,
};
static const struct device_type rc_dev_type = {
.release = rc_dev_release,
.uevent = rc_dev_uevent,
};
struct rc_dev *rc_allocate_device(enum rc_driver_type type)
{
struct rc_dev *dev;
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev)
return NULL;
if (type != RC_DRIVER_IR_RAW_TX) {
dev->input_dev = input_allocate_device();
if (!dev->input_dev) {
kfree(dev);
return NULL;
}
dev->input_dev->getkeycode = ir_getkeycode;
dev->input_dev->setkeycode = ir_setkeycode;
input_set_drvdata(dev->input_dev, dev);
dev->timeout = IR_DEFAULT_TIMEOUT;
timer_setup(&dev->timer_keyup, ir_timer_keyup, 0);
timer_setup(&dev->timer_repeat, ir_timer_repeat, 0);
spin_lock_init(&dev->rc_map.lock);
spin_lock_init(&dev->keylock);
}
[media] rc: add locking to fix register/show race When device_add is called in rc_register_device, the rc sysfs nodes show up, and there's a window in which ir-keytable can be launched via udev and trigger a show_protocols call, which runs without various rc_dev fields filled in yet. Add some locking around registration and store/show_protocols to prevent that from happening. The problem manifests thusly: [64692.957872] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [64692.957878] IP: [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957890] PGD 19cfc7067 PUD 19cfc6067 PMD 0 [64692.957894] Oops: 0000 [#1] SMP [64692.957897] last sysfs file: /sys/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/rc/rc2/protocols [64692.957902] CPU 3 [64692.957903] Modules linked in: redrat3(+) ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_hauppauge ir_nec _decoder rc_core ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_mi di_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem pcsp kr tg3 snd_hwdep emu10k1_gp snd amd64_edac_mod gameport edac_core soundcore edac_mce_amd k8temp shpchp i2c_piix4 lm63 e100 mii uinput ipv6 raid0 rai d1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t sata_svw pata_serverworks floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: redrat3] [64692.957949] [64692.957952] Pid: 12265, comm: ir-keytable Tainted: G M W 2.6.39-rc6+ #2 empty empty/TYAN Thunder K8HM S3892 [64692.957957] RIP: 0010:[<ffffffffa036a4c1>] [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957962] RSP: 0018:ffff880194509e38 EFLAGS: 00010202 [64692.957964] RAX: 0000000000000000 RBX: ffffffffa036d1e0 RCX: ffffffffa036a47a [64692.957966] RDX: ffff88019a84d000 RSI: ffffffffa036d1e0 RDI: ffff88019cf2f3f0 [64692.957969] RBP: ffff880194509e68 R08: 0000000000000002 R09: 0000000000000000 [64692.957971] R10: 0000000000000002 R11: 0000000000001617 R12: ffff88019a84d000 [64692.957973] R13: 0000000000001000 R14: ffff8801944d2e38 R15: ffff88019ce5f190 [64692.957976] FS: 00007f0a30c9a720(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000 [64692.957979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [64692.957981] CR2: 0000000000000090 CR3: 000000019a8e0000 CR4: 00000000000006e0 [64692.957983] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [64692.957986] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [64692.957989] Process ir-keytable (pid: 12265, threadinfo ffff880194508000, task ffff88019a9fc720) [64692.957991] Stack: [64692.957992] 0000000000000002 ffffffffa036d1e0 ffff880194509f58 0000000000001000 [64692.957997] ffff8801944d2e38 ffff88019ce5f190 ffff880194509e98 ffffffff8131484b [64692.958001] ffffffff8118e923 ffffffff810e9b2f ffff880194509e98 ffff8801944d2e18 [64692.958005] Call Trace: [64692.958014] [<ffffffff8131484b>] dev_attr_show+0x27/0x4e [64692.958014] [<ffffffff8118e923>] ? sysfs_read_file+0x94/0x172 [64692.958014] [<ffffffff810e9b2f>] ? __get_free_pages+0x16/0x52 [64692.958014] [<ffffffff8118e94c>] sysfs_read_file+0xbd/0x172 [64692.958014] [<ffffffff8113205e>] vfs_read+0xac/0xf3 [64692.958014] [<ffffffff8113347b>] ? fget_light+0x3a/0xa1 [64692.958014] [<ffffffff811320f2>] sys_read+0x4d/0x74 [64692.958014] [<ffffffff814c19c2>] system_call_fastpath+0x16/0x1b Its a bit difficult to reproduce, but I'm fairly confident this has fixed the problem. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-11 12:14:31 -06:00
mutex_init(&dev->lock);
dev->dev.type = &rc_dev_type;
dev->dev.class = &rc_class;
device_initialize(&dev->dev);
dev->driver_type = type;
__module_get(THIS_MODULE);
return dev;
}
EXPORT_SYMBOL_GPL(rc_allocate_device);
void rc_free_device(struct rc_dev *dev)
{
if (!dev)
return;
input_free_device(dev->input_dev);
put_device(&dev->dev);
/* kfree(dev) will be called by the callback function
rc_dev_release() */
module_put(THIS_MODULE);
}
EXPORT_SYMBOL_GPL(rc_free_device);
static void devm_rc_alloc_release(struct device *dev, void *res)
{
rc_free_device(*(struct rc_dev **)res);
}
struct rc_dev *devm_rc_allocate_device(struct device *dev,
enum rc_driver_type type)
{
struct rc_dev **dr, *rc;
dr = devres_alloc(devm_rc_alloc_release, sizeof(*dr), GFP_KERNEL);
if (!dr)
return NULL;
rc = rc_allocate_device(type);
if (!rc) {
devres_free(dr);
return NULL;
}
rc->dev.parent = dev;
rc->managed_alloc = true;
*dr = rc;
devres_add(dev, dr);
return rc;
}
EXPORT_SYMBOL_GPL(devm_rc_allocate_device);
static int rc_prepare_rx_device(struct rc_dev *dev)
{
int rc;
struct rc_map *rc_map;
u64 rc_proto;
if (!dev->map_name)
return -EINVAL;
rc_map = rc_map_get(dev->map_name);
if (!rc_map)
rc_map = rc_map_get(RC_MAP_EMPTY);
if (!rc_map || !rc_map->scan || rc_map->size == 0)
return -EINVAL;
rc = ir_setkeytable(dev, rc_map);
if (rc)
return rc;
rc_proto = BIT_ULL(rc_map->rc_proto);
if (dev->driver_type == RC_DRIVER_SCANCODE && !dev->change_protocol)
dev->enabled_protocols = dev->allowed_protocols;
if (dev->driver_type == RC_DRIVER_IR_RAW)
ir_raw_load_modules(&rc_proto);
if (dev->change_protocol) {
rc = dev->change_protocol(dev, &rc_proto);
if (rc < 0)
goto out_table;
dev->enabled_protocols = rc_proto;
}
/* Keyboard events */
set_bit(EV_KEY, dev->input_dev->evbit);
set_bit(EV_REP, dev->input_dev->evbit);
set_bit(EV_MSC, dev->input_dev->evbit);
set_bit(MSC_SCAN, dev->input_dev->mscbit);
/* Pointer/mouse events */
set_bit(INPUT_PROP_POINTING_STICK, dev->input_dev->propbit);
set_bit(EV_REL, dev->input_dev->evbit);
set_bit(REL_X, dev->input_dev->relbit);
set_bit(REL_Y, dev->input_dev->relbit);
if (dev->open)
dev->input_dev->open = ir_open;
if (dev->close)
dev->input_dev->close = ir_close;
dev->input_dev->dev.parent = &dev->dev;
memcpy(&dev->input_dev->id, &dev->input_id, sizeof(dev->input_id));
dev->input_dev->phys = dev->input_phys;
dev->input_dev->name = dev->device_name;
return 0;
out_table:
ir_free_table(&dev->rc_map);
return rc;
}
static int rc_setup_rx_device(struct rc_dev *dev)
{
int rc;
/* rc_open will be called here */
rc = input_register_device(dev->input_dev);
if (rc)
return rc;
/*
* Default delay of 250ms is too short for some protocols, especially
* since the timeout is currently set to 250ms. Increase it to 500ms,
* to avoid wrong repetition of the keycodes. Note that this must be
* set after the call to input_register_device().
*/
if (dev->allowed_protocols == RC_PROTO_BIT_CEC)
dev->input_dev->rep[REP_DELAY] = 0;
else
dev->input_dev->rep[REP_DELAY] = 500;
/*
* As a repeat event on protocols like RC-5 and NEC take as long as
* 110/114ms, using 33ms as a repeat period is not the right thing
* to do.
*/
dev->input_dev->rep[REP_PERIOD] = 125;
return 0;
}
static void rc_free_rx_device(struct rc_dev *dev)
{
if (!dev)
return;
if (dev->input_dev) {
input_unregister_device(dev->input_dev);
dev->input_dev = NULL;
}
ir_free_table(&dev->rc_map);
}
int rc_register_device(struct rc_dev *dev)
{
const char *path;
int attr = 0;
int minor;
int rc;
if (!dev)
return -EINVAL;
minor = ida_simple_get(&rc_ida, 0, RC_DEV_MAX, GFP_KERNEL);
if (minor < 0)
return minor;
dev->minor = minor;
dev_set_name(&dev->dev, "rc%u", dev->minor);
dev_set_drvdata(&dev->dev, dev);
dev->dev.groups = dev->sysfs_groups;
if (dev->driver_type == RC_DRIVER_SCANCODE && !dev->change_protocol)
dev->sysfs_groups[attr++] = &rc_dev_ro_protocol_attr_grp;
else if (dev->driver_type != RC_DRIVER_IR_RAW_TX)
dev->sysfs_groups[attr++] = &rc_dev_rw_protocol_attr_grp;
if (dev->s_filter)
dev->sysfs_groups[attr++] = &rc_dev_filter_attr_grp;
if (dev->s_wakeup_filter)
dev->sysfs_groups[attr++] = &rc_dev_wakeup_filter_attr_grp;
dev->sysfs_groups[attr++] = NULL;
if (dev->driver_type == RC_DRIVER_IR_RAW) {
rc = ir_raw_event_prepare(dev);
if (rc < 0)
goto out_minor;
}
if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
rc = rc_prepare_rx_device(dev);
if (rc)
goto out_raw;
}
rc = device_add(&dev->dev);
if (rc)
goto out_rx_free;
path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL);
dev_info(&dev->dev, "%s as %s\n",
dev->device_name ?: "Unspecified device", path ?: "N/A");
kfree(path);
dev->registered = true;
if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
rc = rc_setup_rx_device(dev);
if (rc)
goto out_dev;
}
/* Ensure that the lirc kfifo is setup before we start the thread */
if (dev->allowed_protocols != RC_PROTO_BIT_CEC) {
rc = ir_lirc_register(dev);
if (rc < 0)
goto out_rx;
}
if (dev->driver_type == RC_DRIVER_IR_RAW) {
rc = ir_raw_event_register(dev);
if (rc < 0)
goto out_lirc;
}
dev_dbg(&dev->dev, "Registered rc%u (driver: %s)\n", dev->minor,
dev->driver_name ? dev->driver_name : "unknown");
return 0;
out_lirc:
if (dev->allowed_protocols != RC_PROTO_BIT_CEC)
ir_lirc_unregister(dev);
out_rx:
rc_free_rx_device(dev);
out_dev:
device_del(&dev->dev);
out_rx_free:
ir_free_table(&dev->rc_map);
out_raw:
ir_raw_event_free(dev);
out_minor:
ida_simple_remove(&rc_ida, minor);
return rc;
}
EXPORT_SYMBOL_GPL(rc_register_device);
static void devm_rc_release(struct device *dev, void *res)
{
rc_unregister_device(*(struct rc_dev **)res);
}
int devm_rc_register_device(struct device *parent, struct rc_dev *dev)
{
struct rc_dev **dr;
int ret;
dr = devres_alloc(devm_rc_release, sizeof(*dr), GFP_KERNEL);
if (!dr)
return -ENOMEM;
ret = rc_register_device(dev);
if (ret) {
devres_free(dr);
return ret;
}
*dr = dev;
devres_add(parent, dr);
return 0;
}
EXPORT_SYMBOL_GPL(devm_rc_register_device);
void rc_unregister_device(struct rc_dev *dev)
{
if (!dev)
return;
if (dev->driver_type == RC_DRIVER_IR_RAW)
ir_raw_event_unregister(dev);
del_timer_sync(&dev->timer_keyup);
del_timer_sync(&dev->timer_repeat);
rc_free_rx_device(dev);
mutex_lock(&dev->lock);
if (dev->users && dev->close)
dev->close(dev);
dev->registered = false;
mutex_unlock(&dev->lock);
/*
* lirc device should be freed with dev->registered = false, so
* that userspace polling will get notified.
*/
if (dev->allowed_protocols != RC_PROTO_BIT_CEC)
ir_lirc_unregister(dev);
device_del(&dev->dev);
ida_simple_remove(&rc_ida, dev->minor);
if (!dev->managed_alloc)
rc_free_device(dev);
}
EXPORT_SYMBOL_GPL(rc_unregister_device);
/*
* Init/exit code for the module. Basically, creates/removes /sys/class/rc
*/
static int __init rc_core_init(void)
{
int rc = class_register(&rc_class);
if (rc) {
pr_err("rc_core: unable to register rc class\n");
return rc;
}
rc = lirc_dev_init();
if (rc) {
pr_err("rc_core: unable to init lirc\n");
class_unregister(&rc_class);
return 0;
}
led_trigger_register_simple("rc-feedback", &led_feedback);
rc_map_register(&empty_map);
return 0;
}
static void __exit rc_core_exit(void)
{
lirc_dev_exit();
class_unregister(&rc_class);
led_trigger_unregister_simple(led_feedback);
rc_map_unregister(&empty_map);
}
subsys_initcall(rc_core_init);
module_exit(rc_core_exit);
MODULE_AUTHOR("Mauro Carvalho Chehab");
MODULE_LICENSE("GPL v2");