It makes the printk cleaner. As a side efect, it also fixes those smatch warnings: drivers/media/rc/mceusb.c:590 mceusb_dev_printdata() warn: argument 6 to %02x specifier has type 'char' drivers/media/rc/mceusb.c:590 mceusb_dev_printdata() warn: argument 7 to %02x specifier has type 'char' Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Switch attribute wakeup_data from binary to a text attribute. This makes it easier to handle in userspace and allows to use the output of tools like mode2 almost as is to set a wakeup sequence. Changing to a text format and values in microseconds also makes the userspace interface independent of the setting of SAMPLE_PERIOD in the driver. In addition document the new sysfs attribute in Documentation/ABI/testing/sysfs-class-rc-nuvoton. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on systems supporting infrared. This commit adds the missing line so it works out of the box when built as a module and running on a sunxi system with an infrared receiver. Signed-off-by: Emilio López <emilio.lopez@collabora.co.uk> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Since rc_allocate_device() uses kmalloc, it can returns NULL, so need to check, otherwise, NULL derefenrece can happen. Reported-by: Insu Yun <wuninsu@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Fix AverMedia RM-KS keymap using user guide to meet LinuxTV wiki rules. The remote command didn't seem to change in itself since its creation: it's just to make keys more standard and remove the FIXME. Signed-off-by: Philippe Valembois <lephilousophe@users.sourceforge.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This patch adds a binary attribute /sys/class/rc/rc?/wakeup_data which
allows to read / write the wakeup sequence.
In combination with the core extension for exposing the most recent raw
packet this allows to easily define and set a wakeup sequence.
At least on my Zotac CI321 the BIOS resets the wakeup sequence at each boot
to a factory default. Therefore I use a udev rule
SUBSYSTEM=="rc", DRIVERS=="nuvoton-cir", ACTION=="add", RUN+="<script>"
with the script basically doing
cat <stored wakeup sequence> >/sys${DEVPATH}/wakeup_data
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The device initialization completes only after calling input_register_device(). However, rc_open() can be called while the device is being registered by the input/evdev core. So, we can't expect that rc_dev->initialized to be true. Change the logic to don't require initialized == true at rc_open and change the type of initialized to be atomic. this way, we can check for it earlier where it is really needed, without needing to lock the mutex just for testing it. Tested with nuvoton_cir driver on a NUC5i7RYB with CIR integrated on it. Reported-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
We can only unlock if mutex_lock() succeeds. Fixes the following warning: drivers/media/rc/lirc_dev.c:535 lirc_dev_fop_close() error: double unlock 'mutex:&lirc_dev_lock' Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Instead of having the timeouts hardcoded, and getting only the accel value from the array, put everything in the same place. That simplifies the logic. As a side effect, it also cleans several smatch errors: include/linux/jiffies.h:359:41: error: strange non-value function or array include/linux/jiffies.h:361:42: error: strange non-value function or array (one per time_after/time_before line) Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
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>