kernel.git/drivers/media/rc/ir-lirc-codec.c, branch linux-4.4.y

media: rc: check for integer overflow

2017-11-30T08:37:24Z

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: lirc: LIRC_GET_REC_RESOLUTION should return microseconds

2017-08-11T16:08:50Z

commit 9f5039ba440e499d85c29b1ddbc3cbc9dc90e44b upstream. Since commit e8f4818895b3 ("[media] lirc: advertise LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that the hardware can detect. This breaks decoding in lirc because lircd expects the answer in microseconds, but nanoseconds is returned. Reported-by: Derek Tested-by: Derek Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

[media] rc-core: remove the LIRC "protocol"

2015-07-06T11:26:15Z

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

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

2014-11-04T22:41:42Z

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

[media] rc-core: remove protocol arrays

2014-07-25T22:10:43Z

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

[media] rc: abstract access to allowed/enabled protocols

2014-03-11T16:24:39Z

The allowed and enabled protocol masks need to be expanded to be per filter type in order to support wakeup filter protocol selection. To ease that process abstract access to the rc_dev::allowed_protos and rc_dev::enabled_protocols members with inline functions. Signed-off-by: James Hogan Reviewed-by: Antti Seppälä Signed-off-by: Mauro Carvalho Chehab

[media] media: lirc: Allow lirc dev to talk to rc device

2013-07-31T19:30:27Z

The use case is simple, if any rc device has allowed protocols = RC_TYPE_LIRC and map_name = RC_MAP_LIRC set, the driver open will be never called. The reason for this is, all of the key maps except lirc have some KEYS in there map, so during rc_register_device process these keys are matched against the input drivers and open is performed, so for the case of RC_MAP_EMPTY, a vt/keyboard is matched and the driver open is performed. In case of lirc, there is no match and result is that there is no open performed, however the lirc-dev will go ahead and create a /dev/lirc0 node. Now when lircd/mode2 opens this device, no data is available because the driver was never opened. Other case pointed by Sean Young, As rc device gets opened via the input interface. If the input device is never opened (e.g. embedded with no console) then the rc open is never called and lirc will not work either. So that's another case. lirc_dev seems to have no link with actual rc device w.r.t open/close. This patch adds rc_dev pointer to lirc_driver structure for cases like this, so that it can do the open/close of the real driver in accordance to lircd/mode2 open/close. Without this patch its impossible to open a rc device which has RC_TYPE_LIRC ad RC_MAP_LIRC set. Signed-off-by: Srinivas Kandagatla Signed-off-by: Mauro Carvalho Chehab

[media] lirc: validate transmission ir data

2013-07-30T20:03:16Z

The lirc interface allows 255 u32 spaces and pulses, which are usec. If the driver can handle this (e.g. winbond-cir) you can produce hours of meaningless IR data and there is no method of interrupting it. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2013-05-02T00:51:54Z

Pull VFS updates from Al Viro, Misc cleanups all over the place, mainly wrt /proc interfaces (switch create_proc_entry to proc_create(), get rid of the deprecated create_proc_read_entry() in favor of using proc_create_data() and seq_file etc). 7kloc removed. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (204 commits) don't bother with deferred freeing of fdtables proc: Move non-public stuff from linux/proc_fs.h to fs/proc/internal.h proc: Make the PROC_I() and PDE() macros internal to procfs proc: Supply a function to remove a proc entry by PDE take cgroup_open() and cpuset_open() to fs/proc/base.c ppc: Clean up scanlog ppc: Clean up rtas_flash driver somewhat hostap: proc: Use remove_proc_subtree() drm: proc: Use remove_proc_subtree() drm: proc: Use minor->index to label things, not PDE->name drm: Constify drm_proc_list[] zoran: Don't print proc_dir_entry data in debug reiserfs: Don't access the proc_dir_entry in r_open(), r_start() r_show() proc: Supply an accessor for getting the data from a PDE's parent airo: Use remove_proc_subtree() rtl8192u: Don't need to save device proc dir PDE rtl8187se: Use a dir under /proc/net/r8180/ proc: Add proc_mkdir_data() proc: Move some bits from linux/proc_fs.h to linux/{of.h,signal.h,tty.h} proc: Move PDE_NET() to fs/proc/proc_net.c ...

constify a bunch of struct file_operations instances

2013-04-09T18:16:20Z

Signed-off-by: Al Viro