#
162736b0 |
|
10-Jan-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
driver core: make struct device_type.uevent() take a const * The uevent() callback in struct device_type should not be modifying the device that is passed into it, so mark it as a const * and propagate the function signature changes out into all relevant subsystems that use this callback. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Bard Liao <yung-chuan.liao@linux.intel.com> Cc: Chaitanya Kulkarni <kch@nvidia.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jilin Yuan <yuanjilin@cdjrlc.com> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Len Brown <lenb@kernel.org> Cc: Mark Gross <markgross@kernel.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Cc: Maximilian Luz <luzmaximilian@gmail.com> Cc: Michael Jamet <michael.jamet@intel.com> Cc: Ming Lei <ming.lei@redhat.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Sanyog Kale <sanyog.r.kale@intel.com> Cc: Sean Young <sean@mess.org> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Won Chung <wonchung@google.com> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> # for Thunderbolt Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Vinod Koul <vkoul@kernel.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230111113018.459199-6-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ff62b8e6 |
|
23-Nov-2022 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
driver core: make struct class.devnode() take a const * The devnode() in struct class should not be modifying the device that is passed into it, so mark it as a const * and propagate the function signature changes out into all relevant subsystems that use this callback. Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Reinette Chatre <reinette.chatre@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: x86@kernel.org Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Jens Axboe <axboe@kernel.dk> Cc: Justin Sanders <justin@coraid.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Benjamin Gaignard <benjamin.gaignard@collabora.com> Cc: Liam Mark <lmark@codeaurora.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: John Stultz <jstultz@google.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org> Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Sean Young <sean@mess.org> Cc: Frank Haverkamp <haver@linux.ibm.com> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Xie Yongji <xieyongji@bytedance.com> Cc: Gautam Dawar <gautam.dawar@xilinx.com> Cc: Dan Carpenter <error27@gmail.com> Cc: Eli Cohen <elic@nvidia.com> Cc: Parav Pandit <parav@nvidia.com> Cc: Maxime Coquelin <maxime.coquelin@redhat.com> Cc: alsa-devel@alsa-project.org Cc: dri-devel@lists.freedesktop.org Cc: kvm@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-block@vger.kernel.org Cc: linux-input@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: linux-rdma@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Link: https://lore.kernel.org/r/20221123122523.1332370-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b464763c |
|
08-Jul-2022 |
Marko Mäkelä <marko.makela@iki.fi> |
media: lirc: ensure lirc device receives repeats Pressing a button on a remote control unit will typically lead to messages being sent several times per second until the button is released. Some remote control units indicate long key presses by sending special "repeat" messages, for which the protocol driver calls rc_repeat(). Other units repeat the same message over and over, which will be handled by calling rc_keydown(). The function rc_keydown() never set the LIRC "repeat" flag to distinguish repeated messages that were sent due to a long keypress, and messages sent due to repeated short keypresses. While a user-space program may implement special logic to distinguish long keypresses, it is much simpler to be able to rely on the flag. Commit de142c32410649e64d44928505ffad2176a96a9e ("media: lirc: implement reading scancode") would never set the LIRC_SCANCODE_FLAG_REPEAT flag. Commit b66218fddfd29f315a103db811152ab0c95fb054 ("media: lirc: ensure lirc device receives nec repeats") fixed it up for rc_repeat() but not rc_keydown(). Signed-off-by: Marko Mäkelä <marko.makela@iki.fi> Co-developed-by: Sean Young <sean@mess.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
cd54ff93 |
|
27-May-2022 |
keliu <liuke94@huawei.com> |
media: rc: Directly use ida_free() Use ida_alloc() and ida_free() instead of the deprecated ida_simple_get() and ida_simple_remove(). Signed-off-by: keliu <liuke94@huawei.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
86541f04 |
|
10-Jun-2021 |
lijian <lijian@yulong.com> |
media: rc: rc-main.c: deleted the repeated word deleted the repeated word 'the' in the comments. Signed-off-by: lijian <lijian@yulong.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
f09f9f93 |
|
26-Feb-2021 |
Hans Verkuil <hverkuil@xs4all.nl> |
media: rc: compile rc-cec.c into rc-core The rc-cec keymap is unusual in that it can't be built as a module, instead it is registered directly in rc-main.c if CONFIG_MEDIA_CEC_RC is set. This is because it can be called from drm_dp_cec_set_edid() via cec_register_adapter() in an asynchronous context, and it is not allowed to use request_module() to load rc-cec.ko in that case. Trying to do so results in a 'WARN_ON_ONCE(wait && current_is_async())'. Since this keymap is only used if CONFIG_MEDIA_CEC_RC is set, we just compile this keymap into the rc-core module and never as a separate module. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 2c6d1fffa1d9 (drm: add support for DisplayPort CEC-Tunneling-over-AUX) Reported-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
06b83158 |
|
05-Jan-2021 |
Matthias Reichl <hias@horus.com> |
media: rc: fix timeout handling after switch to microsecond durations Commit 528222d853f92 ("media: rc: harmonize infrared durations to microseconds") missed to switch some timeout calculations from nanoseconds to microseconds. This resulted in spurious key_up+key_down events at the last scancode if the rc device uses a long timeout (eg 100ms on nuvoton-cir) as the device timeout wasn't properly accounted for in the keyup timeout calculation. Fix this by applying the proper conversion functions. Cc: stable@vger.kernel.org Fixes: 528222d853f92 ("media: rc: harmonize infrared durations to microseconds") Signed-off-by: Matthias Reichl <hias@horus.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
896111dc |
|
20-Dec-2020 |
Sean Young <sean@mess.org> |
media: rc: ensure that uevent can be read directly after rc device register There is a race condition where if the /sys/class/rc0/uevent file is read before rc_dev->registered is set to true, -ENODEV will be returned. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1901089 Cc: stable@vger.kernel.org Fixes: a2e2d73fa281 ("media: rc: do not access device via sysfs after rc_unregister_device()") Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
75992a44 |
|
24-Aug-2020 |
Sean Young <sean@mess.org> |
media: rc: rename ir_lirc_* functions to lirc_* Remove pointless ir_ prefix. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
a2e2d73f |
|
08-Aug-2020 |
Sean Young <sean@mess.org> |
media: rc: do not access device via sysfs after rc_unregister_device() Device drivers do not expect to have change_protocol or wakeup re-programming to be accesed after rc_unregister_device(). This can cause the device driver to access deallocated resources. Cc: <stable@vger.kernel.org> # 4.16+ Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
4f0835d6 |
|
08-Aug-2020 |
Sean Young <sean@mess.org> |
media: rc: uevent sysfs file races with rc_unregister_device() Only report uevent file contents if device still registered, else we might read freed memory. Reported-by: syzbot+ceef16277388d6f24898@syzkaller.appspotmail.com Cc: Hillf Danton <hdanton@sina.com> Cc: <stable@vger.kernel.org> # 4.16+ Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
3b4cfc69 |
|
18-Jun-2020 |
Evgeny Novikov <novikov@ispras.ru> |
media: rc: return proper error code on error handling path in init If lirc_dev_init() fails during module initialization, rc_core_init() returns 0 denoting success. This can cause different issues during further operation of the module. The patch fixes the return value of rc_core_init() on the corresponding error handling path. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov <novikov@ispras.ru> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
e6c6d7d4 |
|
17-Jan-2020 |
Sean Young <sean@mess.org> |
media: rc: make scancodes 64 bit There are many protocols that encode more than 32 bit. We want 64 bit support so that BPF IR decoders can decode more than 32 bit. None of the existing kernel IR decoders/encoders support 64 bit, for now. The MSC_SCAN event can only contain 32 bit scancodes, so we only generate MSC_SCAN events if the scancode fits into 32 bits. The full 64 bit scancode can be read from the lirc chardev. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
080d89f5 |
|
21-Nov-2019 |
Sean Young <sean@mess.org> |
media: rc: ensure lirc is initialized before registering input device Once rc_open is called on the input device, lirc events can be delivered. Ensure lirc is ready to do so else we might get this: Registered IR keymap rc-hauppauge rc rc0: Hauppauge WinTV PVR-350 as /devices/pci0000:00/0000:00:1e.0/0000:04:00.0/i2c-0/0-0018/rc/rc0 input: Hauppauge WinTV PVR-350 as /devices/pci0000:00/0000:00:1e.0/0000:04:00.0/i2c-0/0-0018/rc/rc0/input9 BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 5.3.11-300.fc31.x86_64 #1 Hardware name: /DG43NB, BIOS NBG4310H.86A.0096.2009.0903.1845 09/03/2009 Workqueue: events ir_work [ir_kbd_i2c] RIP: 0010:ir_lirc_scancode_event+0x3d/0xb0 Code: a6 b4 07 00 00 49 81 c6 b8 07 00 00 55 53 e8 ba a7 9d ff 4c 89 e7 49 89 45 00 e8 5e 7a 25 00 49 8b 1e 48 89 c5 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:ffffaae2000b3d88 EFLAGS: 00010017 RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000019 RDX: 0000000000000001 RSI: 006e801b1f26ce6a RDI: ffff9e39797c37b4 RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: ffff9e39797c37b4 R13: ffffaae2000b3db8 R14: ffff9e39797c37b8 R15: ffff9e39797c33d8 FS: 0000000000000000(0000) GS:ffff9e397b680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000035844000 CR4: 00000000000006e0 Call Trace: ir_do_keydown+0x8e/0x2b0 rc_keydown+0x52/0xc0 ir_work+0xb8/0x130 [ir_kbd_i2c] process_one_work+0x19d/0x340 worker_thread+0x50/0x3b0 kthread+0xfb/0x130 ? process_one_work+0x340/0x340 ? kthread_park+0x80/0x80 ret_from_fork+0x35/0x40 Modules linked in: rc_hauppauge tuner msp3400 saa7127 saa7115 ivtv(+) tveeprom cx2341x v4l2_common videodev mc i2c_algo_bit ir_kbd_i2c ip_tables firewire_ohci e1000e serio_raw firewire_core ata_generic crc_itu_t pata_acpi pata_jmicron fuse CR2: 0000000000000038 ---[ end trace c67c2697a99fa74b ]--- RIP: 0010:ir_lirc_scancode_event+0x3d/0xb0 Code: a6 b4 07 00 00 49 81 c6 b8 07 00 00 55 53 e8 ba a7 9d ff 4c 89 e7 49 89 45 00 e8 5e 7a 25 00 49 8b 1e 48 89 c5 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:ffffaae2000b3d88 EFLAGS: 00010017 RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000019 RDX: 0000000000000001 RSI: 006e801b1f26ce6a RDI: ffff9e39797c37b4 RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: ffff9e39797c37b4 R13: ffffaae2000b3db8 R14: ffff9e39797c37b8 R15: ffff9e39797c33d8 FS: 0000000000000000(0000) GS:ffff9e397b680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000035844000 CR4: 00000000000006e0 rc rc0: lirc_dev: driver ir_kbd_i2c registered at minor = 0, scancode receiver, no transmitter tuner-simple 0-0061: creating new instance tuner-simple 0-0061: type set to 2 (Philips NTSC (FI1236,FM1236 and compatibles)) ivtv0: Registered device video0 for encoder MPG (4096 kB) ivtv0: Registered device video32 for encoder YUV (2048 kB) ivtv0: Registered device vbi0 for encoder VBI (1024 kB) ivtv0: Registered device video24 for encoder PCM (320 kB) ivtv0: Registered device radio0 for encoder radio ivtv0: Registered device video16 for decoder MPG (1024 kB) ivtv0: Registered device vbi8 for decoder VBI (64 kB) ivtv0: Registered device vbi16 for decoder VOUT ivtv0: Registered device video48 for decoder YUV (1024 kB) Cc: stable@vger.kernel.org Tested-by: Nick French <nickfrench@gmail.com> Reported-by: Nick French <nickfrench@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
ce819649 |
|
28-Sep-2019 |
Sean Young <sean@mess.org> |
media: rc: mark input device as pointing stick libinput refuses pointer movement from rc-core, since it believes it's not a pointer-type device: libinput error: event17 - Media Center Ed. eHome Infrared Remote Transceiver (1784:0008): libinput bug: REL_X/Y from a non-pointer device Fixes: 158bc148a31e ("media: rc: mce_kbd: input events via rc-core's input device") Fixes: 0ac5a603a732 ("media: rc: imon: report mouse events using rc-core's input device") Cc: stable@vger.kernel.org # 4.20+ Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
#
3d351531 |
|
23-May-2019 |
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> |
media: rc-main: clean-up two warnings While correct, the code is too complex for smatch to undersdand that protocol will always be initialized: drivers/media/rc/rc-main.c:1531 store_wakeup_protocols() error: uninitialized symbol 'protocol'. drivers/media/rc/rc-main.c:1541 store_wakeup_protocols() error: uninitialized symbol 'protocol'. So, change it a little bit in order to avoid such warning. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
#
17287692 |
|
24-Mar-2019 |
Matthias Reichl <hias@horus.com> |
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>
|
#
04ad3011 |
|
18-Feb-2019 |
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> |
media: rc: fix several typos Use codespell to fix lots of typos over frontends. Manually verified to avoid false-positives. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
#
05f0edad |
|
22-Feb-2019 |
Sean Young <sean@mess.org> |
media: Revert "media: rc: some events are dropped by userspace" When an rc device is created, we do not know what key codes it will support, since a new keymap might be loaded at some later point. So, we set all keybit in the input device. The uevent for the input device includes all the key codes, of which there are now 768. This overflows the size of the uevent (UEVENT_BUFFER_SIZE) and no event is generated. Revert for now until we figure out a different solution. This reverts commit fec225a04330d0f222d24feb5bea045526031675. Cc: <stable@vger.kernel.org> # 4.20+ Reported-by: Christian Holpert <christian@holpert.de> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
#
721074b0 |
|
17-Jan-2019 |
Patrick Lerda <patrick9876@free.fr> |
media: rc: rcmm decoder and encoder media: add support for RCMM infrared remote controls. Signed-off-by: Patrick Lerda <patrick9876@free.fr> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
#
8e782fcf |
|
04-Nov-2018 |
Sean Young <sean@mess.org> |
media: rc: ensure close() is called on rc_unregister_device If userspace has an open file descriptor on the rc input device or lirc device when rc_unregister_device() is called, then the rc close() is never called. This ensures that the receiver is turned off on the nuvoton-cir driver during shutdown. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
#
e5bb9d3d |
|
22-Oct-2018 |
Sean Young <sean@mess.org> |
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>
|
#
0ac5a603 |
|
16-Sep-2018 |
Sean Young <sean@mess.org> |
media: rc: imon: report mouse events using rc-core's input device There is no need to create another input device. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
#
fec225a0 |
|
18-Sep-2018 |
Sean Young <sean@mess.org> |
media: rc: some events are dropped by userspace libevdev (which is used by libinput) gets a list of keycodes from the input device on creation. Any events with keycodes which are not in this list are silently dropped. So, set all keycodes on device creation since we do not know which will be used if the keymap changes. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
#
f5dbee6e |
|
28-Jul-2018 |
Sean Young <sean@mess.org> |
media: rc: read out of bounds if bpf reports high protocol number The repeat period is read from a static array. If a keydown event is reported from bpf with a high protocol number, we read out of bounds. This is unlikely to end up with a reasonable repeat period at the best of times, in which case no timely key up event is generated. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
#
d7832cd2 |
|
24-May-2018 |
Sean Young <sean@mess.org> |
media: rc: ensure input/lirc device can be opened after register Since commit cb84343fced1 ("media: lirc: do not call close() or open() on unregistered devices") rc_open() will return -ENODEV if rcdev->registered is false. Ensure this is set before we register the input device and the lirc device, else we have a short window where the neither the lirc or input device can be opened. Fixes: cb84343fced1 ("media: lirc: do not call close() or open() on unregistered devices") 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>
|
#
53932760 |
|
07-Apr-2018 |
Sean Young <sean@mess.org> |
media: rc: mce_kbd protocol encodes two scancodes If two keys are pressed, then both keys are encoded in the scancode. This makes the mce keyboard more responsive. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
28492256 |
|
24-Mar-2018 |
Sean Young <sean@mess.org> |
media: rc: per-protocol repeat period and minimum keyup timer Each IR protocol has its own repeat period. We can minimise the keyup timer to be the protocol period + IR timeout. This makes keys less "sticky" and makes IR more reactive and nicer to use. This feature was previously attempted in commit d57ea877af38 ("media: rc: per-protocol repeat period"), but that did not take the IR timeout into account, and had to be reverted. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
a86d6df8 |
|
23-Mar-2018 |
Sean Young <sean@mess.org> |
media: rc: set timeout to smallest value required by enabled protocols The longer the IR timeout, the longer the rc device waits until delivering the trailing space. So, by reducing this timeout, we reduce the delay for the last scancode to be delivered. Note that the lirc daemon disables all protocols, in which case we revert back to the default value. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
447dcc0c |
|
03-Dec-2017 |
Sean Young <sean@mess.org> |
media: rc: add new imon protocol decoder and encoder This makes it possible to use the various iMON remotes with any raw IR RC device. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
8d406881 |
|
06-Mar-2018 |
Sean Young <sean@mess.org> |
media: rc: oops in ir_timer_keyup after device unplug If there is IR in the raw kfifo when ir_raw_event_unregister() is called, then kthread_stop() causes ir_raw_event_thread to be scheduled, decode some scancodes and re-arm timer_keyup. The timer_keyup then fires when the rc device is long gone. Cc: stable@vger.kernel.org Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
1f17f684 |
|
12-Feb-2018 |
Sean Young <sean@mess.org> |
media: rc: remove IR_dprintk() from rc-core Use dev_dbg() rather than custom debug function. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
fb7ccc61 |
|
03-Dec-2017 |
Sean Young <sean@mess.org> |
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>
|
#
57c642cb |
|
23-Nov-2017 |
Sean Young <sean@mess.org> |
media: cec: move cec autorepeat handling to rc-core CEC autorepeat is different than other protocols. Autorepeat is triggered by the first repeated user control pressed CEC message, rather than a fixed REP_DELAY. This change also does away with the KEY_UP event directly after the first KEY_DOWN event, which was used to stop autorepeat from starting. See commit a9a249a2c997 ("media: cec: fix remote control passthrough") for the original change. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
62d6f199 |
|
23-Sep-2017 |
Sean Young <sean@mess.org> |
media: lirc: scancode rc devices should have a lirc device too Now that the lirc interface supports scancodes, RC scancode devices can also have a lirc device. The only receiving feature they will have enabled is LIRC_CAN_REC_SCANCODE. Note that CEC devices have no lirc device, since they can be controlled from their /dev/cecN chardev. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
b66218fd |
|
30-Sep-2017 |
Sean Young <sean@mess.org> |
media: lirc: ensure lirc device receives nec repeats The lirc device should get lirc repeats whether there is a keymap match or not. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
de142c32 |
|
25-Feb-2017 |
Sean Young <sean@mess.org> |
media: lirc: implement reading scancode This implements LIRC_MODE_SCANCODE reading from the lirc device. The scancode can be read from the input device too, but with this interface you get the rc protocol, keycode, toggle and repeat status in addition to just the scancode. int main() { int fd, mode, rc; fd = open("/dev/lirc0", O_RDWR); mode = LIRC_MODE_SCANCODE; if (ioctl(fd, LIRC_SET_REC_MODE, &mode)) { // kernel too old or lirc does not support transmit } struct lirc_scancode scancode; while (read(fd, &scancode, sizeof(scancode)) == sizeof(scancode)) { printf("protocol:%d scancode:0x%x toggle:%d repeat:%d\n", scancode.rc_proto, scancode.scancode, !!(scancode.flags & LIRC_SCANCODE_FLAG_TOGGLE), !!(scancode.flags & LIRC_SCANCODE_FLAG_REPEAT)); } close(fd); } Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
a6ddd4fe |
|
26-Sep-2017 |
Sean Young <sean@mess.org> |
media: lirc: remove last remnants of lirc kapi rc-core has replaced the lirc kapi many years ago, and now with the last driver ported to rc-core, we can finally remove it. Note this has no effect on userspace. All future IR drivers should use the rc-core api. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
cb84343f |
|
23-Sep-2017 |
Sean Young <sean@mess.org> |
media: lirc: do not call close() or open() on unregistered devices If a lirc chardev is held open after a device is unplugged, rc_close() will be called after rc_unregister_device(). The driver is not expecting any calls at this point, and the iguanair driver causes an oops in this scenario. rc_open() can be called when the device is removed too, by calling open on the chardev whilst the device is being removed. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
7790e81f |
|
26-Sep-2017 |
Sean Young <sean@mess.org> |
media: lirc: move lirc_dev->attached to rc_dev->registered This is done to further remove the lirc kernel api. Ensure that every fops checks for this. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
6b514c4a |
|
09-Oct-2017 |
Sean Young <sean@mess.org> |
media: rc: document and fix rc_validate_scancode() For some IR protocols, some scancode values not valid, i.e. they're part of a different protocol variant. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
49a4b36a |
|
27-Sep-2017 |
Sean Young <sean@mess.org> |
media: lirc: validate scancode for transmit Ensure we reject an attempt to transmit invalid scancodes. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
a60d64b1 |
|
23-Sep-2017 |
Sean Young <sean@mess.org> |
media: lirc: lirc interface should not be a raw decoder The lirc user interface exists as a raw decoder, which does not make much sense for transmit-only devices. In addition, we want to have lirc char devices for devices which do not use raw IR, i.e. scancode only devices. Note that rc-code, lirc_dev, ir-lirc-codec are now calling functions of each other, so they've been merged into one module rc-core to avoid circular dependencies. Since ir-lirc-codec no longer exists as separate codec module, there is no need for RC_DRIVER_IR_RAW_TX type drivers to call ir_raw_event_register(). Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
0d39ab0b |
|
25-Feb-2017 |
Sean Young <sean@mess.org> |
media: rc: auto load encoder if necessary When sending scancodes, load the encoder if we need it. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
20835280 |
|
01-Dec-2017 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
media: rc: add SPDX identifiers to the code I wrote As we're now using SPDX identifiers, on the several media drivers I wrote, add the proper SPDX, identifying the license I meant. As we're now using the short license, it doesn't make sense to keep the original license text. Also, fix MODULE_LICENSE to properly identify GPL v2. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
67f0f15a |
|
19-Nov-2017 |
Sean Young <sean@mess.org> |
media: rc: partial revert of "media: rc: per-protocol repeat period" Since commit d57ea877af38 ("media: rc: per-protocol repeat period"), most IR protocols have a lower keyup timeout. This causes problems on the ite-cir, which has default IR timeout of 200ms. Since the IR decoders read the trailing space, with a IR timeout of 200ms, the last keydown will have at least a delay of 200ms. This is more than the protocol timeout of e.g. rc-6 (which is 164ms). As a result the last IR will be interpreted as a new keydown event, and we get two keypresses. Revert the protocol timeout to 250ms, except for cec which needs a timeout of 550ms. Fixes: d57ea877af38 ("media: rc: per-protocol repeat period") Cc: <stable@vger.kernel.org> # 4.14 Reported-by: Matthias Reichl <hias@horus.com> Signed-off-by: Sean Young <sean@mess.org> Tested-by: Matthias Reichl <hias@horus.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
f67f366c |
|
27-Nov-2017 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
media: rc: fix lots of documentation warnings Building the driver with gcc 7.2.1 and: make ARCH=i386 CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 CHECK='' M=drivers/media now produces a lot of warnings: drivers/media/rc/rc-main.c:278: warning: No description found for parameter 'new_keycode' drivers/media/rc/rc-main.c:278: warning: Excess function parameter 'keycode' description in 'ir_update_mapping' drivers/media/rc/rc-main.c:387: warning: No description found for parameter 'ke' drivers/media/rc/rc-main.c:387: warning: No description found for parameter 'old_keycode' drivers/media/rc/rc-main.c:387: warning: Excess function parameter 'scancode' description in 'ir_setkeycode' drivers/media/rc/rc-main.c:387: warning: Excess function parameter 'keycode' description in 'ir_setkeycode' drivers/media/rc/rc-main.c:433: warning: Excess function parameter 'to' description in 'ir_setkeytable' drivers/media/rc/rc-main.c:506: warning: No description found for parameter 'ke' drivers/media/rc/rc-main.c:506: warning: Excess function parameter 'scancode' description in 'ir_getkeycode' drivers/media/rc/rc-main.c:506: warning: Excess function parameter 'keycode' description in 'ir_getkeycode' drivers/media/rc/rc-main.c:634: warning: No description found for parameter 't' drivers/media/rc/rc-main.c:634: warning: Excess function parameter 'cookie' description in 'ir_timer_keyup' Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
b17ec78a |
|
24-Oct-2017 |
Kees Cook <keescook@chromium.org> |
media: rc: Convert timers to use timer_setup() In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: James Hogan <jhogan@kernel.org> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: "Antti Seppälä" <a.seppala@gmail.com> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: "David Härdeman" <david@hardeman.nu> Cc: Andi Shyti <andi.shyti@samsung.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
d7a6795b |
|
18-Sep-2017 |
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> |
[media] media: rc: Delete duplicate debug message ir_setkeytable() and ir_create_table() print the same debug message. Delete the one in ir_setkeytable() Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
8ca01d4f |
|
08-Sep-2017 |
Thomas Meyer <thomas@m3y3r.de> |
[media] media: rc: Use bsearch library function Replace self coded binary search, by existing library version. Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
b9f407e3 |
|
01-Sep-2017 |
Sean Young <sean@mess.org> |
[media] media: rc: include device name in rc udev event This name is also stored in the input's device name, but that is not available in TX only hardware (no input device). Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
6d75db30 |
|
01-Sep-2017 |
Sean Young <sean@mess.org> |
[media] media: rc: if protocols can't be changed, don't be writable If the protocols of an rc device cannot be changed, ensure the sysfs file is not writable. This makes it possible to detect this from userspace, so ir-keytable can deal with case without giving an error. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
831c4c81 |
|
01-Sep-2017 |
Sean Young <sean@mess.org> |
[media] media: rc: ensure that protocols are enabled for scancode drivers rc scancode drivers without change_protocol should have all protocols enabled at all time. This was only true for cec and ir-kbd-i2c. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
f03f02f9 |
|
19-Aug-2017 |
Bhumika Goyal <bhumirks@gmail.com> |
[media] media: rc: make device_type const Make this const as it is only stored in the type field of a device structure, which is const. Done using Coccinelle. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
6d741bfe |
|
07-Aug-2017 |
Sean Young <sean@mess.org> |
media: rc: rename RC_TYPE_* to RC_PROTO_* and RC_BIT_* to RC_PROTO_BIT_* RC_TYPE is confusing and it's just the protocol. So rename it. Suggested-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sean Young <sean@mess.org> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
d57ea877 |
|
09-Aug-2017 |
Sean Young <sean@mess.org> |
media: rc: per-protocol repeat period CEC needs a keypress timeout of 550ms, which is too high for the IR protocols. Also fill in known repeat times, with 50ms error margin. Also, combine all protocol data into one structure. Signed-off-by: Sean Young <sean@mess.org> Suggested-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
2168b416 |
|
07-Aug-2017 |
Sean Young <sean@mess.org> |
media: rc: ensure we do not read out of bounds If rc_validate_filter() is called for CEC or XMP, then we would read beyond the end of the array. Suggested-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
518f4b26 |
|
30-Jun-2017 |
Sean Young <sean@mess.org> |
media: rc-core: rename input_name to device_name When an ir-spi is registered, you get this message. rc rc0: Unspecified device as /devices/platform/soc/3f215080.spi/spi_master/spi32766/spi32766.128/rc/rc0 "Unspecified device" refers to input_name, which makes no sense for IR TX only devices. So, rename to device_name. Also make driver_name const char* so that no casts are needed anywhere. Now ir-spi reports: rc rc0: IR SPI as /devices/platform/soc/3f215080.spi/spi_master/spi32766/spi32766.128/rc/rc0 Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
db68102c |
|
07-Jul-2017 |
Arvind Yadav <arvind.yadav.cs@gmail.com> |
media: rc: constify attribute_group structures attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. File size before: text data bss dec hex filename 11605 880 20 12505 30d9 drivers/media/rc/rc-main.o File size After adding 'const': text data bss dec hex filename 11797 720 20 12537 30f9 drivers/media/rc/rc-main.o Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
265a2988 |
|
22-Jun-2017 |
David Härdeman <david@hardeman.nu> |
media: rc-core: consistent use of rc_repeat() The NEC decoder and the Sanyo decoders check if dev->keypressed is true before calling rc_repeat (without holding dev->keylock). Meanwhile, the XMP and JVC decoders do no such checks. This patch makes sure all users of rc_repeat() do so consistently by removing extra checks in NEC/Sanyo and modifying the check a bit in rc_repeat() so that no input event is generated if the key isn't pressed. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
18726a34 |
|
27-Apr-2017 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: cleanup rc_register_device pt2 Now that rc_register_device() is reorganised, the dev->initialized hack can be removed. Any driver which calls rc_register_device() must be prepared for the device to go live immediately. The dev->initialized commits that are relevant are commit c73bbaa4ec3e ("[media] rc-core: don't lock device at rc_register_device()") and commit 08aeb7c9a42a ("[media] rc: add locking to fix register/show race"). The original problem was that show_protocols() would access dev->rc_map.* and various other bits which are now properly initialized before device_add() is called. At the same time, remove the bogus "device is being removed" check. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
f56928ab |
|
03-May-2017 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: cleanup rc_register_device The device core infrastructure is based on the presumption that once a driver calls device_add(), it must be ready to accept userspace interaction. This requires splitting rc_setup_rx_device() into two functions and reorganizing rc_register_device() so that as much work as possible is performed before calling device_add(). Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
b2aceb73 |
|
27-Apr-2017 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: fix input repeat handling The call to input_register_device() needs to take place before the repeat parameters are set or the input subsystem repeat handling will be disabled (as was already noted in the comments in that function). Cc: stable <stable@vger.kernel.org> # v4.11 Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
b73bc16d |
|
11-Feb-2017 |
Sean Young <sean@mess.org> |
[media] mce_kbd: add encoder Split the protocol into two variants, one for keyboard and one for mouse data. Note that the mce_kbd protocol cannot be used on the igorplugusb, since the IR is too long. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
5df62771 |
|
23-Feb-2017 |
Sean Young <sean@mess.org> |
[media] rc: protocol is not set on register for raw IR devices ir_raw_event_register() sets up change_protocol(), and without that set, rc_setup_rx_device() does not set the protocol for the device on register. The standard udev rules run ir-keytable, which writes to the protocols file again, which hides this problem. Fixes: 7ff2c2b ("[media] rc-main: split setup and unregister functions") Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
41380868 |
|
22-Feb-2017 |
Sean Young <sean@mess.org> |
[media] rc: raw decoder for keymap protocol is not loaded on register When the protocol is set via the sysfs protocols attribute, the decoder is loaded. However, when it is not when a device is first plugged in or registered. Fixes: acc1c3c ("[media] media: rc: load decoder modules on-demand") Signed-off-by: Sean Young <sean@mess.org> Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
8caebcdc |
|
19-Jan-2017 |
Sean Young <sean@mess.org> |
[media] rc: remove excessive spaces from error message The current message has some wanted spaces on it: rc_core: Loaded IR protocol module ir-jvc-decoder, but protocol jvc still not available Merge it into a single line. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
d34aee10 |
|
15-Dec-2016 |
Andi Shyti <andi@etezian.org> |
[media] rc-core: add support for IR raw transmitters IR raw transmitter driver type is specified in the enum rc_driver_type as RC_DRIVER_IR_RAW_TX which includes all those devices that transmit raw stream of bit to a receiver. The data are provided by userspace applications, therefore they don't need any input device allocation, but still they need to be registered as raw devices. Suggested-by: Sean Young <sean@mess.org> Signed-off-by: Andi Shyti <andi.shyti@samsung.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
7ff2c2bc |
|
15-Dec-2016 |
Andi Shyti <andi@etezian.org> |
[media] rc-main: split setup and unregister functions Move the input device allocation, map and protocol handling to different functions. Signed-off-by: Andi Shyti <andi.shyti@samsung.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
0f7499fd |
|
16-Dec-2016 |
Andi Shyti <andi@etezian.org> |
[media] rc-main: assign driver type during allocation The driver type can be assigned immediately when an RC device requests to the framework to allocate the device. This is an 'enum rc_driver_type' data type and specifies whether the device is a raw receiver or scancode receiver. The type will be given as parameter to the rc_allocate_device device. Change accordingly all the drivers calling rc_allocate_device() so that the device type is specified during the rc device allocation. Whenever the device type is not specified, it will be set as RC_DRIVER_SCANCODE which was the default '0' value. Suggested-by: Sean Young <sean@mess.org> Signed-off-by: Andi Shyti <andi.shyti@samsung.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
f423ccc1 |
|
31-Mar-2015 |
James Hogan <jhogan@kernel.org> |
[media] rc: rc-core: Add support for encode_wakeup drivers Add support in rc-core for drivers which implement the wakeup scancode filter by encoding the scancode using the raw IR encoders. This is by way of rc_dev::encode_wakeup which should be set to true and rc_dev::allowed_wakeup_protocols should be set to the raw IR encoders. We also do not permit the mask to be set as we cannot generate IR which would match that. Signed-off-by: James Hogan <james@albanarts.com> Signed-off-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Cc: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
b590c0bf |
|
05-Dec-2016 |
Sean Young <sean@mess.org> |
[media] rc: Add scancode validation We need to valdiate that scancodes are valid for their protocol; an incorrect necx scancode could actually be a nec scancode, for example. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
0751d33c |
|
05-Dec-2016 |
Sean Young <sean@mess.org> |
[media] rc: change wakeup_protocols to list all protocol variants For IR wakeup, a driver has to program the hardware to wakeup at a specific IR sequence, so it makes no sense to allow multiple wakeup protocols to be selected. In the same manner the sysfs interface only allows one scancode to be provided. In addition, we need to know the specific variant of the protocol. In short, these changes are made to the wakeup_protocols sysfs entry: - list all the protocol variants rather than the protocol groups, e.g. "nec nec-x nec-32" rather than just "nec". - only allow one protocol variant to be selected rather than multiple - wakeup_filter can only be set once a protocol has been selected in wakeup_protocols. This is an API change, however the only user of this API is the img-ir, but the wakeup code was never merged to mainline, so it was never used. Signed-off-by: Sean Young <sean@mess.org> Cc: James Hogan <james.hogan@imgtec.com> Cc: Sifan Naeem <sifan.naeem@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
0fcd3f0a |
|
02-Dec-2016 |
Sean Young <sean@mess.org> |
[media] rc5x: document that this is the 20 bit variant There are many variants of extended rc5. This implements the 20 bit version. Signed-off-by: Sean Young <sean@mess.org> Cc: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
c183d358 |
|
09-Aug-2016 |
Max Kellermann <max.kellermann@gmail.com> |
[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>
|
#
d3d96820 |
|
20-Oct-2016 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc-main: use pr_foo() macros Instead of calling printk() directly, use pr_foo() macro. That should make the rc_core messages be formatted with the right prefix. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
ddbf7d5a |
|
30-Sep-2016 |
Heiner Kallweit <hkallweit1@gmail.com> |
[media] rc: core: add managed versions of rc_allocate_device and rc_register_device Introduce managed versions of both functions. They allows to simplify the error path in the probe function of rc drivers, and usually also to simplify the remove function. New element managed_alloc in struct rc_dev is needed to correctly handle mixed use, e.g. managed version of rc_register_device and normal version of rc_allocate_device. In addition devm_rc_allocate_device sets rc->dev.parent as having a reference to the parent device might be useful for future extensions. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
25ec587c |
|
18-Oct-2016 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc: don't break long lines Due to the 80-cols restrictions, and latter due to checkpatch warnings, several strings were broken into multiple lines. This is not considered a good practice anymore, as it makes harder to grep for strings at the source code. As we're right now fixing other drivers due to KERN_CONT, we need to be able to identify what printk strings don't end with a "\n". It is a way easier to detect those if we don't break long lines. So, join those continuation lines. The patch was generated via the script below, and manually adjusted if needed. </script> use Text::Tabs; while (<>) { if ($next ne "") { $c=$_; if ($c =~ /^\s+\"(.*)/) { $c2=$1; $next =~ s/\"\n$//; $n = expand($next); $funpos = index($n, '('); $pos = index($c2, '",'); if ($funpos && $pos > 0) { $s1 = substr $c2, 0, $pos + 2; $s2 = ' ' x ($funpos + 1) . substr $c2, $pos + 2; $s2 =~ s/^\s+//; $s2 = ' ' x ($funpos + 1) . $s2 if ($s2 ne ""); print unexpand("$next$s1\n"); print unexpand("$s2\n") if ($s2 ne ""); } else { print "$next$c2\n"; } $next=""; next; } else { print $next; } $next=""; } else { if (m/\"$/) { if (!m/\\n\"$/) { $next=$_; next; } } } print $_; } </script> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
2ceeca04 |
|
21-Sep-2016 |
Sean Young <sean@mess.org> |
[media] rc: split nec protocol into its three variants Currently we do not know what variant (bit length) of the nec protocol is used, other than from guessing from the length of the scancode. Now nec will be handled the same way as the sony protocol or the rc6 protocol; one variant per bit length. In the future we might want to expose the rc protocol type to userspace and we don't want to be introducing this world of pain into userspace too. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
552001e6 |
|
30-Jul-2016 |
Ole Ernst <olebowle@gmx.com> |
[media] Partly revert "[media] rc-core: allow calling rc_open with device not initialized" This partly reverts commit 078600f514a12fd763ac84c86af68ef5b5267563. Due to the relocation of input_register_device() call, holding down a button on an IR remote no longer resulted in repeated key down events. Signed-off-by: Ole Ernst <olebowle@gmx.com> Tested-by: Matthias Reichl <hias@horus.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
d54fc3bb |
|
26-Jun-2016 |
Hans Verkuil <hverkuil@xs4all.nl> |
[media] rc-main: fix kernel oops after unloading keymap module When the rc_map table is created the char pointer of the name of the keymap is copied to the rc_map->name field. However, this pointer points to memory from the keymap module itself. Since these keymap modules are not refcounted, that means anyone can call rmmod to unload that module. Which is not a big deal because the contents of the map is all copied to rc_map, except for the keymap name. So after a keymap module is unloaded the name pointer has become stale. Unloading the rc-core module will now cause a kernel oops in rc_dev_uevent(). The solution is to kstrdup the name so there are no more references to the keymap module remaining. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
ff42c8aa |
|
17-Aug-2015 |
Kamil Debski <kamil@wypas.org> |
[media] rc: Add HDMI CEC protocol handling Add handling of remote control events coming from the HDMI CEC bus and the new protocol required for that. Signed-off-by: Kamil Debski <kamil@wypas.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
47cae1e1 |
|
21-Mar-2016 |
Max Kellermann <max@duempel.org> |
[media] drivers/media/rc: postpone kfree(rc_dev) CONFIG_DEBUG_KOBJECT_RELEASE found this bug. Signed-off-by: Max Kellermann <max@duempel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
36ac2f32 |
|
16-Mar-2016 |
Heiner Kallweit <hkallweit1@gmail.com> |
[media] media: rc: remove unneeded mutex in rc_register_device Access to dev->initialized is atomic and dev->initialized isn't accessed in any other code protected by this mutex. Therefore we don't need to get the mutex here. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
078600f5 |
|
02-Mar-2016 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc-core: allow calling rc_open with device not initialized 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>
|
#
c73bbaa4 |
|
11-Feb-2016 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[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>
|
#
c1500ba0 |
|
20-Nov-2015 |
Heiner Kallweit <hkallweit1@gmail.com> |
[media] media: rc: remove unneeded code Now that that the decoder modules are loaded on-demand we can move loading the lirc module to rc_register_device directly and remove unneeded functions and comments. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
|
#
53df8777 |
|
16-Nov-2015 |
Heiner Kallweit <hkallweit1@gmail.com> |
[media] media: rc: constify struct proto_names Declare struct proto_names and its member name as const. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
9f0bf366 |
|
16-Nov-2015 |
Heiner Kallweit <hkallweit1@gmail.com> |
[media] media: rc: preparation for on-demand decoder module loading Prepare on-demand decoder module loading by adding a module_name member to struct proto_names and introducing the related load function. After this patch of the series the decoder modules are still loaded unconditionally. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
4dc0e908 |
|
29-Oct-2015 |
Heiner Kallweit <hkallweit1@gmail.com> |
[media] media: rc-core: simplify logging in rc_register_device Simplify the logging. I had some doubts about using the elvis operator as it's GNU extension. However GNU extensions are explicitely allowed and this operator is used at several places in the kernel code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
2ff56fad |
|
15-Oct-2015 |
Russell King <rmk+kernel@arm.linux.org.uk> |
[media] rc: allow rc modules to be loaded if rc-main is not a module rc-main mistakenly uses #ifdef MODULE to determine whether it should load the rc keymap modules. This symbol is only defined if rc-main is being built as a module itself, and bears no relation to whether the rc keymaps are modules. Fix this to use CONFIG_MODULES instead. Fixes: 631493ecacd8 ("[media] rc-core: merge rc-map.c into rc-main.c") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
3a03b86f |
|
20-Jul-2015 |
David Härdeman <david@hardeman.nu> |
Revert "[media] rc: rc-core: Add support for encode_wakeup drivers" This reverts commit 0d830b2d1295fee82546d57185da5a6604f11ae2. The current code is not mature enough, the API should allow a single protocol to be specified. Also, the current code contains heuristics that will depend on module load order. Signed-off-by: David Härdeman <david@hardeman.nu> Acked-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
dd6ff6a0 |
|
22-Jul-2015 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: improve the lirc protocol reporting Commit 275ddb40bcf686d210d86c6718e42425a6a0bc76 removed the lirc "protocol" but kept backwards compatibility by always listing the protocol as present and enabled. This patch further improves the logic by only listing the protocol if the lirc module is loaded (or if lirc is builtin). Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
275ddb40 |
|
19-May-2015 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: remove the LIRC "protocol" The LIRC protocol was always a bad fit and if we're ever going to expose protocol numbers in a user-space API, it'd be better to get rid of the LIRC "protocol" first. The sysfs API is kept backwards compatible by always listing the lirc protocol as present and enabled. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
fcb13097 |
|
19-May-2015 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: use an IDA rather than a bitmap This patch changes rc-core to use the kernel facilities that are already available for handling unique numbers instead of rolling its own bitmap stuff. Signed-off-by: David Härdeman <david@hardeman.nu> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
a66b0c41 |
|
19-May-2015 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: fix remove uevent generation The input_dev is already gone when the rc device is being unregistered so checking for its presence only means that no remove uevent will be generated. Cc: stable@kernel.org Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
0d830b2d |
|
31-Mar-2015 |
James Hogan <jhogan@kernel.org> |
[media] rc: rc-core: Add support for encode_wakeup drivers Add support in rc-core for drivers which implement the wakeup scancode filter by encoding the scancode using the raw IR encoders. This is by way of rc_dev::encode_wakeup which should be set to true to make the allowed wakeup protocols the same as the set of raw IR encoders. As well as updating the sysfs interface to know which wakeup protocols are allowed for encode_wakeup drivers, also ensure that the IR decoders/encoders are loaded when an encode_wakeup driver is registered. Signed-off-by: James Hogan <james@albanarts.com> Signed-off-by: Antti Seppälä <a.seppala@gmail.com> Cc: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
81b7d14e |
|
28-Apr-2015 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc: fix bad indenting drivers/media/rc/rc-main.c:749 rc_close() warn: inconsistent indenting There's an extra space there. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
983c5bd2 |
|
08-Dec-2014 |
James Hogan <jhogan@kernel.org> |
[media] rc-main: Re-apply filter for no-op protocol change Since commit da6e162d6a46 ("[media] rc-core: simplify sysfs code"), when the IR protocol is set using the sysfs interface to the same set of protocols that are already set, store_protocols() does not refresh the scancode filter with the new protocol, even if it has already called the change_protocol() callback successfully. This results in the filter being disabled in the hardware and not re-enabled until the filter is set again using sysfs. Fix in store_protocols() by still re-applying the filter whenever the change_protocol() driver callback succeeded. The problem can be reproduced with the img-ir driver by setting a filter, and then setting the protocol to the same protocol that is already set: $ echo nec > protocols $ echo 0xffff > filter_mask $ echo nec > protocols After this, messages which don't match the filter were still being received. Fixes: da6e162d6a46 ("[media] rc-core: simplify sysfs code") Reported-by: Sifan Naeem <sifan.naeem@imgtec.com> Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: David Härdeman <david@hardeman.nu> Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
3dd94f00 |
|
20-Nov-2014 |
Markus Elfring <elfring@users.sourceforge.net> |
[media] rc: Deletion of unnecessary checks before two function calls The functions input_free_device() and rc_close() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
fb9b1641 |
|
05-Nov-2014 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc-main: Fix rc_type handling As reported by smatch: drivers/media/rc/rc-main.c:1426 rc_register_device() warn: should '1 << rc_map->rc_type' be a 64 bit type? Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
37fa8716 |
|
30-Sep-2014 |
Tomas Melin <tomas.melin@iki.fi> |
[media] rc-main: fix lockdep splash for rc-main lockdep reports a potential circular dependecy deadlock when registering input device. Unlock mutex rc_dev->lock prior to calling ir_raw_event_register to avoid the circular dependency since that function also calls input_register_device and rc_open. ====================================================== [ INFO: possible circular locking dependency detected ] 3.17.0-rc7+ #24 Not tainted ------------------------------------------------------- modprobe/647 is trying to acquire lock: (input_mutex){+.+.+.}, at: [<ffffffff812ed81c>] input_register_device+0x2ba/0x381 but task is already holding lock: (ir_raw_handler_lock){+.+.+.}, at: [<ffffffff813186ed>] ir_raw_event_register+0x102/0x190 which lock already depends on the new lock. [cut text] other info that might help us debug this: Chain exists of: input_mutex --> &dev->lock --> ir_raw_handler_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(ir_raw_handler_lock); lock(&dev->lock); lock(ir_raw_handler_lock); lock(input_mutex); *** DEADLOCK *** 4 locks held by modprobe/647: #0: (&dev->mutex){......}, at: [<ffffffff812d19f3>] device_lock+0xf/0x11 #1: (&dev->mutex){......}, at: [<ffffffff812d19f3>] device_lock+0xf/0x11 #2: (&dev->lock){+.+.+.}, at: [<ffffffff81317fff>] rc_register_device+0x55d/0x58a #3: (ir_raw_handler_lock){+.+.+.}, at: [<ffffffff813186ed>] ir_raw_event_register+0x102/0x190 stack backtrace: CPU: 0 PID: 647 Comm: modprobe Not tainted 3.17.0-rc7+ #24 Call Trace: [<ffffffff81489d6a>] dump_stack+0x46/0x58 [<ffffffff81487699>] print_circular_bug+0x1f8/0x209 [<ffffffff81074353>] __lock_acquire+0xb54/0xeda [<ffffffff81080f17>] ? console_unlock+0x34d/0x399 [<ffffffff81074c01>] lock_acquire+0xd9/0x111 [<ffffffff812ed81c>] ? input_register_device+0x2ba/0x381 [<ffffffff8148e650>] mutex_lock_interruptible_nested+0x57/0x381 [<ffffffff812ed81c>] ? input_register_device+0x2ba/0x381 [<ffffffff81124e03>] ? kfree+0x7c/0x96 [<ffffffff812ed81c>] ? input_register_device+0x2ba/0x381 [<ffffffff81072531>] ? trace_hardirqs_on+0xd/0xf [<ffffffff812ed81c>] input_register_device+0x2ba/0x381 [<ffffffff8131a537>] ir_mce_kbd_register+0x109/0x139 [<ffffffff81318728>] ir_raw_event_register+0x13d/0x190 [<ffffffff81317e40>] rc_register_device+0x39e/0x58a [<ffffffff81072531>] ? trace_hardirqs_on+0xd/0xf [<ffffffffa00cf2e3>] nvt_probe+0x5ad/0xd52 [nuvoton_cir] [<ffffffffa00ced36>] ? nvt_resume+0x80/0x80 [nuvoton_cir] [<ffffffff81296003>] pnp_device_probe+0x8c/0xa9 [<ffffffff812d1b94>] ? driver_sysfs_add+0x6e/0x93 [<ffffffff812d203a>] driver_probe_device+0xa1/0x1e3 [<ffffffff812d217c>] ? driver_probe_device+0x1e3/0x1e3 [<ffffffff812d21ca>] __driver_attach+0x4e/0x6f [<ffffffff812d075b>] bus_for_each_dev+0x5a/0x8c [<ffffffff812d1b24>] driver_attach+0x19/0x1b [<ffffffff812d1879>] bus_add_driver+0xf1/0x1d6 [<ffffffff812d2817>] driver_register+0x87/0xbe [<ffffffffa0120000>] ? 0xffffffffa0120000 [<ffffffff81295da4>] pnp_register_driver+0x1c/0x1e [<ffffffffa0120010>] nvt_init+0x10/0x1000 [nuvoton_cir] [<ffffffff8100030e>] do_one_initcall+0xea/0x18c [<ffffffff8111497f>] ? __vunmap+0x9d/0xc7 [<ffffffff810a3ca1>] load_module+0x1c21/0x1f2c [<ffffffff810a0bce>] ? show_initstate+0x44/0x44 [<ffffffff810a404e>] SyS_init_module+0xa2/0xb1 [<ffffffff81490ed2>] system_call_fastpath+0x16/0x1b Signed-off-by: Tomas Melin <tomas.melin@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
14edb593 |
|
28-Oct-2014 |
Tomas Melin <tomas.melin@iki.fi> |
[media] rc-core: fix protocol_change regression in ir_raw_event_register IR receiver using nuvoton-cir and lirc required additional configuration steps after upgrade from kernel 3.16 to 3.17-rcX. Bisected regression to commit da6e162d6a4607362f8478c715c797d84d449f8b ("[media] rc-core: simplify sysfs code"). The regression comes from adding function change_protocol in ir-raw.c. It changes behaviour so that only the protocol enabled by driver's map_name will be active after registration. This breaks user space behaviour, lirc does not get key press signals anymore. Enable lirc protocol by default for ir raw decoders to restore original behaviour. Cc: stable@vger.kernel.org # for v3.17 Signed-off-by: Tomas Melin <tomas.melin@iki.fi> Acked-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
#
d24b69fc |
|
28-Jul-2014 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc-main: allow raw protocol drivers to restrict the allowed protos On some hardware (au0828/au8522), the hardware is broken with regards to the initial pulse detection. So, the driver needs to produce a fake start pulse. That limits the acceptable protocols, as it is not possible to produce a fake pulse that would cover all supported protocols. So, allow the driver to explicitly set the allowed protocols. If the driver doesn't specify, keep the old behavior. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
1dee9b59 |
|
26-Jul-2014 |
Marcel J.E. Mol <marcel@mesa.nl> |
[media] rc: Add support for decoding XMP protocol This protocol is found on Dreambox remotes [m.chehab@samsung.com: CodingStyle fixes and conflict fix] Signed-off-by: Marcel Mol <marcel@mesa.nl> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
9d2f1d3c |
|
03-Apr-2014 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: rename dev->scanmask to dev->scancode_mask We already have dev->scancode_filter and dev->scancode_wakeup_filter so rename dev->scanmask to dev->scancode_mask for consistency. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
c5540fbb |
|
03-Apr-2014 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: remove protocol arrays The basic API of rc-core used to be: dev = rc_allocate_device(); dev->x = a; dev->y = b; dev->z = c; rc_register_device(); which is a pretty common pattern in the kernel, after the introduction of protocol arrays the API looks something like: dev = rc_allocate_device(); dev->x = a; rc_set_allowed_protocols(dev, RC_BIT_X); dev->z = c; rc_register_device(); There's no real need for the protocols to be an array, so change it back to be consistent (and in preparation for the following patches). [m.chehab@samsung.com: added missing changes at some files] Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
da6e162d |
|
03-Apr-2014 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: simplify sysfs code Simplify and cleanup the sysfs code a bit. [m.chehab@samsung.com: rebased and fixed a CodingStyle issue] Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
120703f9 |
|
03-Apr-2014 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: document the protocol type Right now the protocol information is not preserved, rc-core gets handed a scancode but has no idea which protocol it corresponds to. This patch (which required reading through the source/keymap for all drivers, not fun) makes the protocol information explicit which is important documentation and makes it easier to e.g. support multiple protocols with one decoder (think rc5 and rc-streamzap). The information isn't used yet so there should be no functional changes. [m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing] Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
99b0f3c9 |
|
04-Apr-2014 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: remove generic scancode filter The generic scancode filtering has questionable value and makes it impossible to determine from userspace if there is an actual scancode hw filter present or not. So revert the generic parts. Based on a patch from James Hogan <james.hogan@imgtec.com>, but this version also makes sure that only the valid sysfs files are created in the first place. Signed-off-by: David Härdeman <david@hardeman.nu> Acked-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
23c843b5 |
|
04-Apr-2014 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: split dev->s_filter Overloading dev->s_filter to do two different functions (set wakeup filters and generic hardware filters) makes it impossible to tell what the hardware actually supports, so create a separate dev->s_wakeup_filter and make the distinction explicit. Signed-off-by: David Härdeman <david@hardeman.nu> Acked-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
8ea5488a |
|
11-Mar-2014 |
Kees Cook <keescook@chromium.org> |
[media] media: rc-core: use %s in rc_map_get() module load rc_map_get() takes a single string literal for the module to load, so make sure it cannot be used as a format string in the call to request_module(). Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
26291233 |
|
01-Mar-2014 |
James Hogan <jhogan@kernel.org> |
[media] rc-main: fix missing unlock if no devno left While playing with make coccicheck I noticed this message: drivers/media/rc/rc-main.c:1245:3-9: preceding lock on line 1238 It was introduced by commit 587d1b06e07b ([media] rc-core: reuse device numbers) which returns -ENOMEM after a mutex_lock without first unlocking it when there are no more device numbers left. The added code doesn't depend on the device lock, so move it before the lock is taken. Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
6bea25af |
|
28-Feb-2014 |
James Hogan <jhogan@kernel.org> |
[media] rc-main: automatically refresh filter on protocol change When either of the normal or wakeup filter protocols are changed, refresh the corresponding scancode filter, i.e. try and set the same scancode filter with the new protocol. If that fails clear the filter instead. If no protocol was selected the filter is just cleared, and if no s_filter callback exists the filter is left unmodified. Similarly clear the filter mask when the filter is set if no protocol is currently selected. This simplifies driver code which no longer has to explicitly worry about modifying the filter on a protocol change. This also allows the change_wakeup_protocol callback to be omitted entirely if there is only a single available wakeup protocol at a time, since selecting no protocol will automatically clear the wakeup filter, disabling wakeup. Signed-off-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
ab88c66d |
|
28-Feb-2014 |
James Hogan <jhogan@kernel.org> |
[media] rc: add wakeup_protocols sysfs file Add a wakeup_protocols sysfs file which controls the new rc_dev::enabled_protocols[RC_FILTER_WAKEUP], which is the mask of protocols that are used for the wakeup filter. A new RC driver callback change_wakeup_protocol() is called to change the wakeup protocol mask. Signed-off-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
acff5f24 |
|
28-Feb-2014 |
James Hogan <jhogan@kernel.org> |
[media] rc: add allowed/enabled wakeup protocol masks Only a single allowed and enabled protocol mask currently exists in struct rc_dev, however to support a separate wakeup filter protocol two of each are needed, ideally as an array. Therefore make both rc_dev::allowed_protos and rc_dev::enabled_protocols arrays, update all users to reference the first element (RC_FILTER_NORMAL), and add a couple more helper functions for drivers to use for setting the allowed and enabled wakeup protocols. We also rename allowed_protos to allowed_protocols while we're at it, which is more consistent with enabled_protocols. Signed-off-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
b8c7d915 |
|
28-Feb-2014 |
James Hogan <jhogan@kernel.org> |
[media] rc-main: add generic scancode filtering Add generic scancode filtering of RC input events, and fall back to permitting any RC_FILTER_NORMAL scancode filter to be set if no s_filter callback exists. This allows raw IR decoder events to be filtered, and potentially allows hardware decoders to set looser filters and rely on generic code to filter out the corner cases. Signed-off-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
7b802ce7 |
|
10-Feb-2014 |
James Hogan <jhogan@kernel.org> |
[media] rc-main: store_filter: pass errors to userland Propagate errors returned by drivers from the s_filter callback back to userland when updating scancode filters. This allows userland to see when the filter couldn't be updated, usually because it's not a valid filter for the hardware. Previously the filter was being updated conditionally on success of s_filter, but the write always reported success back to userland. Reported-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
37e59f87 |
|
07-Feb-2014 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media, edac] Change my email address There are several left overs with my old email address. Remove their occurrences and add myself at CREDITS, to allow people to be able to reach me on my new addresses. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
00942d1a |
|
17-Jan-2014 |
James Hogan <jhogan@kernel.org> |
[media] media: rc: add sysfs scancode filtering interface Add and document a generic sysfs based scancode filtering interface for making use of IR data matching hardware to filter out uninteresting scancodes. Two filters exist, one for normal operation and one for filtering scancodes which are permitted to wake the system from suspend. The following files are added to /sys/class/rc/rc?/: - filter: normal scancode filter value - filter_mask: normal scancode filter mask - wakeup_filter: wakeup scancode filter value - wakeup_filter_mask: wakeup scancode filter mask A new s_filter() driver callback is added which must arrange for the specified filter to be applied at the right time. Drivers can convert the scancode filter into a raw IR data filter, which can be applied immediately or later (for wake up filters). Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: linux-media@vger.kernel.org Cc: Rob Landley <rob@landley.net> Cc: linux-doc@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
38f2a214 |
|
17-Jan-2014 |
James Hogan <jhogan@kernel.org> |
[media] media: rc: add Sharp infrared protocol Add Sharp infrared protocol constants RC_TYPE_SHARP and RC_BIT_SHARP. Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
70a2f912 |
|
16-Jan-2014 |
James Hogan <jhogan@kernel.org> |
[media] media: rc: only turn on LED if keypress generated Since v3.12, specifically 153a60bb0fac ([media] rc: add feedback led trigger for rc keypresses), an LED trigger is activated on IR keydown whether or not a keypress is generated (i.e. even if there's no matching keycode). However the repeat and keyup logic isn't used unless there is a keypress, which results in non-keypress keydown events turning on the LED and not turning it off again. On the assumption that the intent was for the LED only to light up on valid key presses (you probably don't want it lighting up for the wrong remote control for example), move the led_trigger_event() call inside the keycode check. Signed-off-by: James Hogan <james.hogan@imgtec.com> Acked-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
692a228e |
|
15-Jan-2014 |
Fengguang Wu <fengguang.wu@intel.com> |
[media] rc-core: ir_core_dev_number can be static Fix sparse warning: drivers/media/rc/rc-main.c:27:1: sparse: symbol 'ir_core_dev_number' was not declared. Should it be static? Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
587d1b06 |
|
14-Jan-2014 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc-core: reuse device numbers Before changeset d8b4b5822f51e, the remote controller device numbers were released when the device were unregistered. That helped to maintain some sanity, as, when USB devices are replugged, the remote controller would get the same number. Restore the same behaviour. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
f02dcdd1 |
|
16-Aug-2013 |
Juergen Lock <nox@jelal.kn-bremen.de> |
[media] media: rc: rdev->open or rdev->close can be NULL At least technisat-usb2.c doesn't set these... Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
153a60bb |
|
30-Jul-2013 |
Sean Young <sean@mess.org> |
[media] rc: add feedback led trigger for rc keypresses Many devices with an ir receiver also have a feedback led. Add the led trigger to support this. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
8b2ff320 |
|
22-Jul-2013 |
Srinivas Kandagatla <srinivas.kandagatla@st.com> |
[media] media: rc: Add rc_open/close and use count to rc_dev This patch adds user count to rc_dev structure, the reason to add this new member is to allow other code like lirc to open rc device directly. In the existing code, rc device is only opened by input subsystem which works ok if we have any input drivers to match. But in case like lirc where there will be no input driver, rc device will be never opened. Having this user count variable will be usefull to allow rc device to be opened from code other than rc-main. This patch also adds rc_open and rc_close functions for other drivers like lirc to open and close rc devices. This functions safely increment and decrement the user count. Other driver wanting to open rc device should call rc_open and rc_close, rather than directly modifying the rc_dev structure. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
#
9719afae |
|
06-Mar-2013 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: don't treat dev->rc_map.rc_type as a bitmap store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for two reasons. First of all, it is pretty bogus to change the protocol type of the keymap just because the hardware has been asked to decode a different protocol. Second, dev->rc_map.rc_type is an enum (i.e. a single protocol) as pointed out by James Hogan <james.hogan@imgtec.com>. Fix both issues by introducing a separate enabled_protocols member to struct rc_dev. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
40fc5325 |
|
06-Mar-2013 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: rename ir_input_class to rc_class The name is already misleading and will be more so in the future as the connection to the input subsystem is obscured away further. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
e76d4ce4 |
|
06-Mar-2013 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: initialize rc-core earlier if built-in rc-core is a subsystem so it should be registered earlier if built into the kernel. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
afe5624b |
|
27-Nov-2012 |
Dan Carpenter <dan.carpenter@oracle.com> |
[media] rc: unlock on error in store_protocols() This error path is missing the unlock. [mchehab@redhat.com: Merged two equal patches into one] Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Acked-by: David Härdeman <david@hardeman.nu> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
30ebc5e4 |
|
27-Nov-2012 |
Dan Carpenter <dan.carpenter@oracle.com> |
[media] rc: unlock on error in show_protocols() We recently introduced a new return -ENODEV in this function but we need to unlock before returning. [mchehab@redhat.com: found two patches with the same fix. Merged SOB's/acks into one patch] Acked-by: Herton R. Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: Douglas Bagnall <douglas@paradise.net.nz> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
c003ab1b |
|
11-Oct-2012 |
David Härdeman <david@hardeman.nu> |
[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>
|
#
720bb643 |
|
06-Jul-2012 |
Douglas Bagnall <douglas@paradise.net.nz> |
[media] Avoid sysfs oops when an rc_dev's raw device is absent For some reason, when the lirc daemon learns that a usb remote control has been unplugged, it wants to read the sysfs attributes of the disappearing device. This is useful for uncovering transient inconsistencies, but less so for keeping the system running when such inconsistencies exist. Under some circumstances (like every time I unplug my dvb stick from my laptop), lirc catches an rc_dev whose raw event handler has been removed (presumably by ir_raw_event_unregister), and proceeds to interrogate the raw protocols supported by the NULL pointer. This patch avoids the NULL dereference, and ignores the issue of how this state of affairs came about in the first place. Version 2 incorporates changes recommended by Mauro Carvalho Chehab (-ENODEV instead of -EINVAL, and a signed-off-by). Signed-off-by: Douglas Bagnall <douglas@paradise.net.nz> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
5da6e984 |
|
15-Mar-2012 |
Ezequiel García <elezegarcia@gmail.com> |
[media] rc: Pospone ir raw decoders loading until really needed This changes rc_core to not load the IR decoders at load time, postponing it to load only if a RC_DRIVER_IR_RAW device is registered via rc_register_device. We use a static boolean variable, to ensure decoders modules are only loaded once. Tested with rc-loopback device only. Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
2c9ede55 |
|
23-Jul-2011 |
Al Viro <viro@zeniv.linux.org.uk> |
switch device_get_devnode() and ->devnode() to umode_t * both callers of device_get_devnode() are only interested in lower 16bits and nobody tries to return anything wider than 16bit anyway. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
b32e7243 |
|
22-Nov-2011 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc: Add support for decoding Sanyo protocol This protocol is found on Sanyo/Aiwa remotes. Tested with an Aiwa RC-7AS06 remote control. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
7a707b89 |
|
03-Jul-2011 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
drivers/media: Add module.h to all files using it implicitly A pending cleanup will mean that module.h won't be implicitly everywhere anymore. Make sure the modular drivers in clocksource are actually calling out for <module.h> explicitly in advance. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
#
b05681b9 |
|
28-Jul-2011 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc-main: Fix device de-registration logic rc unregister logic were deadly broken, preventing some drivers to be removed. Among the broken things, rc_dev_uevent() is being called during device_del(), causing a data filling on an area that it is not ready anymore. Also, some drivers have a stop callback defined, that needs to be called before data removal, as it stops data polling. Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
f5f2cc64 |
|
13-Jul-2011 |
Jarod Wilson <jarod@redhat.com> |
[media] rc-core support for Microsoft IR keyboard/mouse This is a custom IR protocol decoder, for the RC-6-ish protocol used by the Microsoft Remote Keyboard, apparently developed internally at Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and transceiver requirements and specifications document, which also touches on this IR keyboard/mouse device. Its a standard keyboard with embedded thumb stick mouse pointer and mouse buttons, along with a number of media keys. The media keys are standard RC-6, identical to the signals from the stock MCE remotes, and will be handled as such. The keyboard and mouse signals will be decoded and delivered to the system by an input device registered specifically by this driver. Successfully tested with multiple mceusb-driven transceivers, as well as with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware with enough sampling resolution should be able to use this decoder, nothing about it is at all receiver-hardware-specific. This work is inspired by lirc_mod_mce: The documentation there and code aided in understanding and decoding the protocol, but the bulk of the code is actually borrowed more from the existing in-kernel decoders than anything. I did recycle the keyboard keycode table, a few defines, and some of the keyboard and mouse data parsing bits from lirc_mod_mce though. Special thanks to James Meyer for providing the hardware, and being patient with me as I took forever to get around to writing this. callback routine to ensure we don't get any stuck keys, and used symbolic names for the keytable. Also cc'ing Florian this time, who I believe is the original mod-mce author... CC: Florian Demski <fdemski@users.sourceforge.net> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
0528f354 |
|
26-May-2011 |
Dan Carpenter <error27@gmail.com> |
[media] rc: double unlock in rc_register_device() If change_protocol() fails and we goto out_raw, then it calls unlock twice. I noticed that the other time we called change_protocol() we held the &dev->lock, so I changed it to hold it here too. Reviewed-by: Jarod Wilson <jarod@redhat.com> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
98c32bcd |
|
23-Jun-2011 |
Jarod Wilson <jarod@redhat.com> |
[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>
|
#
ca540c8b |
|
11-May-2011 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] Use a more consistent value for RC repeat period The default REP_PERIOD is 33 ms. This doesn't make sense for IR's, as, in general, an IR repeat scancode is provided at every 110/115ms, depending on the RC protocol. So, increase its default, to do a better job avoiding ghost repeat events. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Acked-by: Jarod Wilson <jarod@redhat.com>
|
#
08aeb7c9 |
|
11-May-2011 |
Jarod Wilson <jarod@redhat.com> |
[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>
|
#
88fda561 |
|
21-Feb-2011 |
Hussam Al-Tayeb <ht990332@gmail.com> |
[media] rc_core: avoid kernel oops when rmmod saa7134 The following is a patch to avoid a kernel oops when running rmmod saa7134 on kernel 2.6.27.1. The change is as suggested by mchehab on irc.freenode.org Signed-off-by: Hussam Al-Tayeb <ht990332@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
b3003933 |
|
25-Apr-2011 |
Jarod Wilson <jarod@redhat.com> |
[media] rc: show RC_TYPE_OTHER in sysfs Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
25985edc |
|
30-Mar-2011 |
Lucas De Marchi <lucas.demarchi@profusion.mobi> |
Fix common misspellings Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
|
#
0a91be40 |
|
13-Feb-2011 |
Antti Seppälä <a.seppala@gmail.com> |
[media] Fix sysfs rc protocol lookup for rc-5-sz With the current matching rules the lookup for rc protocol named rc-5-sz matches with "rc-5" before finding "rc-5-sz". Thus one is able to never enable/disable the rc-5-sz protocol via sysfs. Fix the lookup to require an exact match which allows the manipulation of sz protocol. Signed-off-by: Antti Seppälä <a.seppala@gmail.com> Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
aebd636b |
|
31-Jan-2011 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
Input: switch completely over to the new versions of get/setkeycode All users of old style get/setkeycode methids have been converted so it is time to retire them. Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
#
54e74b87 |
|
29-Jan-2011 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
Input: rc-keymap - return KEY_RESERVED for unknown mappings Do not respond with -EINVAL to EVIOCGKEYCODE for not-yet-mapped scancodes, but rather return KEY_RESERVED. This fixes breakage with Ubuntu's input-kbd utility that stopped returning full keymaps for remote controls. Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by: Mark Lord <kernel@teksavvy.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
dea8a39f |
|
29-Nov-2010 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc-core: Initialize return value to zero At ir_setkeycode, if INPUT_KEYMAP_BY_INDEX is used, the routine may return an invalid value if not error. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
829ba9fe |
|
19-Nov-2010 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: fix some leftovers from the renaming patches Fix some minor comments etc which are leftover from the old naming scheme. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
d100e659 |
|
17-Nov-2010 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc: use rc_map_ prefix for all rc map tables Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
2f4f58d6 |
|
17-Nov-2010 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc: Name RC keymap tables as rc_map_table Remote keytables had different names all over the place. Part of the fault is due to a bad naming when rc subsystem was created, but there were lots of old names that were still here. Use a common standard for everything. Patch generated by this script: for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_scancode,rc_map_table,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_codes_,rc_map_,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,rc_key_map,rc_map_table,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,rc_map_table_size,rc_map_size,g <$i >a && mv a $i; done Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
b088ba65 |
|
17-Nov-2010 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc: Properly name the rc_map struct The struct that describes a rc mapping had an weird and long name. We should properly name it, to make easier for developers to work with it, and to avoid confusion. Basically, generated by this script: for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_scancode_table,rc_map,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,rc_tab,rc_map,g <$i >a && mv a $i; done (and manually fixed where needed) Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
52b66144 |
|
17-Nov-2010 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc: Rename remote controller type to rc_type instead of ir_type for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,IR_TYPE,RC_TYPE,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_type,rc_type,g <$i >a && mv a $i; done Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
ca86674b |
|
17-Nov-2010 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] Rename all public generic RC functions from ir_ to rc_ Those functions are not InfraRed specific. So, rename them to properly reflect it. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
6bda9644 |
|
17-Nov-2010 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc: rename the remaining things to rc_core The Remote Controller subsystem is meant to be used not only by Infra Red but also for similar types of Remote Controllers. The core is not specific to Infra Red. As such, rename: - ir-core.h to rc-core.h - IR_CORE to RC_CORE - namespace inside rc-core.c/rc-core.h To be consistent with the other changes. No functional change on this patch. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
d8b4b582 |
|
29-Oct-2010 |
David Härdeman <david@hardeman.nu> |
[media] ir-core: make struct rc_dev the primary interface This patch merges the ir_input_dev and ir_dev_props structs into a single struct called rc_dev. The drivers and various functions in rc-core used by the drivers are also changed to use rc_dev as the primary interface when dealing with rc-core. This means that the input_dev is abstracted away from the drivers which is necessary if we ever want to support multiple input devs per rc device. The new API is similar to what the input subsystem uses, i.e: rc_device_alloc() rc_device_free() rc_device_register() rc_device_unregister() [mchehab@redhat.com: Fix compilation on mceusb and cx231xx, due to merge conflicts] Signed-off-by: David Härdeman <david@hardeman.nu> Acked-by: Jarod Wilson <jarod@redhat.com> Tested-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
4c7b355d |
|
10-Nov-2010 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: Code cleanup after merging rc-sysfs and rc-map into rc-main [mchehab@redhat.com: this patch were originally bundled with some renaming stuff and with the file merges, as seen at: https://patchwork.kernel.org/patch/291092/. Instead of using the original approach, I wrote the rename patches and the code merge as separate changes, then applied the difference on this patch. This way, it is easier to see the real changes at the code, and will be easier to merge upstream, especially if some conflict rises on the renaming patches] Signed-off-by: David Härdeman <david@hardeman.nu> Acked-by: Jarod Wilson <jarod@redhat.com> Tested-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
631493ec |
|
09-Nov-2010 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc-core: merge rc-map.c into rc-main.c With this change, all rc-core functions are into just one file, except for the rc-raw specific functions. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
bc2a6c57 |
|
09-Nov-2010 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] rc-core: Merge rc-sysfs.c into rc-main.c Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
#
f62de675 |
|
09-Nov-2010 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
[media] Rename rc-core files from ir- to rc- As protocol decoders are specific to InfraRed, keep their names as-is. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|