Commit Graph

11 Commits

Author SHA1 Message Date
David Härdeman
9719afae5e [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>
2013-03-23 11:25:54 -03:00
David Härdeman
c003ab1bed [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>
2012-10-27 11:49:51 -02:00
Joe Perches
86b0dbef77 [media] rc-core.h: Surround macro with do {} while (0)
Macros coded with if statements should be do { if... } while (0)
so the macros can be used in other if tests.

Use ##__VA_ARGS__ for variadic macro as well.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-09-03 20:56:22 -03:00
David Härdeman
5588dc2b02 [media] rc-core: lirc use unsigned int
Durations can never be negative, so it makes sense to consistently use
unsigned int for LIRC transmission. Contrary to the initial impression,
this shouldn't actually change the userspace API.

Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-27 17:52:59 -03:00
Jarod Wilson
08aeb7c9a4 [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>
2011-05-20 16:21:22 -03:00
Jarod Wilson
5aad724280 [media] rc: fix up and genericize some time unit conversions
The ene_ir driver was using a private define of MS_TO_NS, which is meant
to be microseconds to nanoseconds. The mceusb driver copied it,
intending to use is a milliseconds to microseconds. Lets move the
defines to a common location, expand and standardize them a touch, so
that we now have:

  MS_TO_NS - milliseconds to nanoseconds
  MS_TO_US - milliseconds to microseconds
  US_TO_NS - microseconds to nanoseconds

Reported-by: David Härdeman <david@hardeman.nu>
CC: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:52 -02:00
David Härdeman
829ba9fe34 [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>
2010-12-29 08:16:54 -02:00
Mauro Carvalho Chehab
b088ba658b [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>
2010-12-29 08:16:51 -02:00
Mauro Carvalho Chehab
52b661449a [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>
2010-12-29 08:16:50 -02:00
Mauro Carvalho Chehab
ca86674b8a [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>
2010-12-29 08:16:50 -02:00
Mauro Carvalho Chehab
6bda96447c [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>
2010-12-29 08:16:50 -02:00