linux-stable.git/drivers/media/rc, branch linux-3.18.y

mceusb: sporadic RX truncation corruption fix

2018-04-13T17:52:19+00:00

[ Upstream commit 8e175b22e8640bf3a58e071af54190b909e4a944 ]

Intermittent RX truncation and loss of IR received data. This resulted
in receive stream synchronization errors where driver attempted to
incorrectly parse IR data (eg 0x90 below) as command response.

[ 3969.139898] mceusb 1-1.2:1.0: processed IR data
[ 3969.151315] mceusb 1-1.2:1.0: rx data: 00 90 (length=2)
[ 3969.151321] mceusb 1-1.2:1.0: Unknown command 0x00 0x90
[ 3969.151336] mceusb 1-1.2:1.0: rx data: 98 0a 8d 0a 8e 0a 8e 0a 8e 0a 8e 0a 9a 0a 8e 0a 0b 3a 8e 00 80 41 59 00 00 (length=25)
[ 3969.151341] mceusb 1-1.2:1.0: Raw IR data, 24 pulse/space samples
[ 3969.151348] mceusb 1-1.2:1.0: Storing space with duration 500000

Bug trigger appears to be normal, but heavy, IR receiver use.

Signed-off-by: A Sun 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

media: rc: check for integer overflow

2017-11-30T08:35:53+00:00

commit 3e45067f94bbd61dec0619b1c32744eb0de480c8 upstream.

The ioctl LIRC_SET_REC_TIMEOUT would set a timeout of 704ns if called
with a timeout of 4294968us.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: imon: Fix null-ptr-deref in imon_probe

2017-11-21T08:01:04+00:00

commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.

It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.

Signed-off-by: Arvind Yadav 
Tested-by: Andrey Konovalov 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

ir-core: fix gcc-7 warning on bool arithmetic

2017-07-27T22:03:23+00:00

commit bd7e31bbade02bc1e92aa00d5cf2cee2da66838a upstream.

gcc-7 suggests that an expression using a bitwise not and a bitmask
on a 'bool' variable is better written using boolean logic:

drivers/media/rc/imon.c: In function 'imon_incoming_scancode':
drivers/media/rc/imon.c:1725:22: error: '~' on a boolean expression [-Werror=bool-operation]
    ictx->pad_mouse = ~(ictx->pad_mouse) & 0x1;
                      ^
drivers/media/rc/imon.c:1725:22: note: did you mean to use logical not?

I agree.

Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver")

Signed-off-by: Arnd Bergmann 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

mceusb: fix NULL-deref at probe

2017-05-25T12:17:58+00:00

commit 03eb2a557ed552e920a0942b774aaf931596eec1 upstream.

Make sure to check for the required out endpoint to avoid dereferencing
a NULL-pointer in mce_request_packet should a malicious device lack such
an endpoint. Note that this path is hit during probe.

Fixes: 66e89522aff7 ("V4L/DVB: IR: add mceusb IR receiver driver")

Signed-off-by: Johan Hovold 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

[media] Fix RC5 decoding with Fintek CIR chipset

2016-08-22T16:23:06+00:00

[ Upstream commit bbdb34c90aeb8b2253eae88029788ebe1d7f2fd4 ]

Fix RC5 decoding with Fintek CIR chipset

Commit e87b540be2dd02552fb9244d50ae8b4e4619a34b tightened up the RC5
decoding by adding a check for trailing silence to ensure a valid RC5
command had been received. Unfortunately the trailer length checked was
10 units and the Fintek CIR device does not want to provide details of a
space longer than 6350us. This meant that RC5 remotes working on a
Fintek setup on 3.16 failed on 3.17 and later. Fix this by shortening
the trailer check to 6 units (allowing for a previous space in the
received remote command).

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117221

Signed-off-by: Jonathan McDowell 
Cc: stable@vger.kernel.org
Signed-off-by: David Härdeman 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

[media] rc-core: fix remove uevent generation

2015-10-07T14:16:04+00:00

[ Upstream commit a66b0c41ad277ae62a3ae6ac430a71882f899557 ]

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 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

[media] rc: img-ir: fix error in parameters passed to irq_free()

2015-05-17T23:12:21+00:00

[ Upstream commit 80ccf4ad06dc9d2f06a8347b2d309cdc959f72b3 ]

img_ir_remove() passes a pointer to the ISR function as the 2nd
parameter to irq_free() instead of a pointer to the device data
structure.
This issue causes unloading img-ir module to fail with the below
warning after building and loading img-ir as a module.

WARNING: CPU: 2 PID: 155 at ../kernel/irq/manage.c:1278
__free_irq+0xb4/0x214() Trying to free already-free IRQ 58
Modules linked in: img_ir(-)
CPU: 2 PID: 155 Comm: rmmod Not tainted 3.14.0 #55 ...
Call Trace:
...
[<8048d420>] __free_irq+0xb4/0x214
[<8048d6b4>] free_irq+0xac/0xf4
[] img_ir_remove+0x54/0xd4 [img_ir] [<8073ded0>]
platform_drv_remove+0x30/0x54 ...

Fixes: 160a8f8aec4d ("[media] rc: img-ir: add base driver")

Signed-off-by: Sifan Naeem 
Cc:  # 3.15+
Acked-by: James Hogan 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

rc-main: Re-apply filter for no-op protocol change

2015-03-06T22:52:51+00:00

commit 983c5bd26b86ba1c0d79b770e596bb8b77e42f32 upstream.

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 
Signed-off-by: James Hogan 
Cc: David Härdeman 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media/rc: Send sync space information on the lirc device

2015-02-27T01:49:02+00:00

commit a8f29e89f2b54fbf2c52be341f149bc195b63a8b upstream.

Userspace expects to see a long space before the first pulse is sent on
the lirc device.  Currently, if a long time has passed and a new packet
is started, the lirc codec just returns and doesn't send anything.  This
makes lircd ignore many perfectly valid signals unless they are sent in
quick sucession.  When a reset event is delivered, we cannot know
anything about the duration of the space.  But it should be safe to
assume it has been a long time and we just set the duration to maximum.

Signed-off-by: Austin Lund 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman