linux-toradex.git/drivers/media/rc/ir-lirc-codec.c, branch v4.14

media: lirc: LIRC_GET_REC_RESOLUTION should return microseconds

2017-07-26T09:46:42+00:00

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.

Cc:  # v2.6.36+
Reported-by: Derek 
Tested-by: Derek 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc_dev: remove unused set_use_inc/set_use_dec

2017-06-06T12:00:11+00:00

Since there are no users of this functionality, it can be removed
altogether.

Signed-off-by: David Härdeman 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc_dev: remove pointless functions

2017-06-06T11:59:28+00:00

drv->set_use_inc and drv->set_use_dec are already optional so we can
remove all dummy functions.

Signed-off-by: David Härdeman 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

[media] ir-lirc-codec: let lirc_dev handle the lirc_buffer

2017-05-18T09:19:29+00:00

ir_lirc_register() currently creates its own lirc_buffer before
passing the lirc_driver to lirc_register_driver().

When a module is later unloaded, ir_lirc_unregister() gets called
which performs a call to lirc_unregister_driver() and then free():s
the lirc_buffer.

The problem is that:

a) there can still be a userspace app holding an open lirc fd
   when lirc_unregister_driver() returns; and

b) the lirc_buffer contains "wait_queue_head_t wait_poll" which
   is potentially used as long as any userspace app is still around.

The result is an oops which can be triggered quite easily by a
userspace app monitoring its lirc fd using epoll() and not closing
the fd promptly on device removal.

The minimalistic fix is to let lirc_dev create the lirc_buffer since
lirc_dev will then also free the buffer once it believes it is safe to
do so.

Signed-off-by: David Härdeman 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc: advertise LIRC_CAN_GET_REC_RESOLUTION and improve

2017-03-24T11:23:18+00:00

This feature was never set. The ioctl should fail if no resolution
is set.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc: return ENOTTY when device does support ioctl

2017-03-24T11:20:28+00:00

If timeouts or carrier range is not supported, return proper error.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc: return ENOTTY when ioctl is not supported

2017-03-24T10:44:42+00:00

We shouldn't be using ENOSYS when a feature is not available. I've tested
lirc; nothing is broken as far as I can make out.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc: LIRC_GET_MIN_TIMEOUT should be in range

2017-01-31T09:30:22+00:00

LIRC_SET_REC_TIMEOUT can fail if the value returned by
LIRC_GET_MIN_TIMEOUT is set due to rounding errors.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc: fix transmit-only read features

2017-01-31T09:28:18+00:00

An RC device which is transmit-only shouldn't have the
LIRC_CAN_REC_MODE2 feature.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc: LIRC_{G,S}ET_SEND_MODE fail if device cannot transmit

2017-01-30T13:53:02+00:00

These ioctls should not succeed if the device cannot send. Also make it
clear that these ioctls should return the lirc mode, although the actual
value does not change.

Signed-off-by: Sean Young 
Reviewed-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab