On 06/13/2010 01:29 PM, David Härdeman wrote:
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index daf33c1..7ae5662 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -33,122 +33,178 @@ static struct class ir_input_class = {
  };

  /**
- * show_protocol() - shows the current IR protocol
+ * show_protocols() - shows the current IR protocol(s)
   * @d:                the device descriptor
   * @mattr:    the device attribute struct (unused)
   * @buf:      a pointer to the output buffer
   *
- * This routine is a callback routine for input read the IR protocol type.
- * it is trigged by reading /sys/class/rc/rc?/current_protocol.
- * It returns the protocol name, as understood by the driver.
+ * This routine is a callback routine for input read the IR protocol type(s).
+ * it is trigged by reading /sys/class/rc/rc?/protocols.
+ * It returns the protocol names of supported protocols.
+ * Enabled protocols are printed in brackets.
   */
-static ssize_t show_protocol(struct device *d,
-                            struct device_attribute *mattr, char *buf)
+static ssize_t show_protocols(struct device *d,
+                             struct device_attribute *mattr, char *buf)
  {
-       char *s;
        struct ir_input_dev *ir_dev = dev_get_drvdata(d);
-       u64 ir_type = ir_dev->rc_tab.ir_type;
-
-       IR_dprintk(1, "Current protocol is %lld\n", (long long)ir_type);
-
-       /* FIXME: doesn't support multiple protocols at the same time */
-       if (ir_type == IR_TYPE_UNKNOWN)
-               s = "Unknown";
-       else if (ir_type == IR_TYPE_RC5)
-               s = "rc-5";
-       else if (ir_type == IR_TYPE_NEC)
-               s = "nec";
-       else if (ir_type == IR_TYPE_RC6)
-               s = "rc6";
-       else if (ir_type == IR_TYPE_JVC)
-               s = "jvc";
-       else if (ir_type == IR_TYPE_SONY)
-               s = "sony";
-       else
-               s = "other";
+       u64 allowed, enabled;
+       char *tmp = buf;
+
+       if (ir_dev->props->driver_type == RC_DRIVER_SCANCODE) {

This change introduced an oops for me. On my saa7134 MSI TV Anywhere Plus, ir_dev->props is null, so dereferencing it causes the following while attempting to read /sys/devices/virtual/rc/rc0/protocols:

[ 601.632041] BUG: unable to handle kernel NULL pointer dereference at (null)
[  601.632061] IP: [<ffffffffa00f43b5>] show_protocols+0x25/0x120 [ir_core]
[  601.632079] PGD 7b181067 PUD 7bafe067 PMD 0
[  601.632093] Oops: 0000 [#1] SMP
[  601.632103] last sysfs file: /sys/devices/virtual/rc/rc0/protocols
[  601.632111] CPU 0
[ 601.632115] Modules linked in: binfmt_misc rfcomm parport_pc ppdev sco bnep l2cap saa7134_alsa arc4 rc_msi_tvanywhere_plus ir_kbd_i2c advantechwdt tda827x rt2500pci rt2x00pci rt2x00lib snd_intel8x0 tda8290 snd_ac97_codec led_class ac97_bus tuner snd_seq_midi snd_rawmidi ir_lirc_codec lirc_dev mac80211 cfg80211 snd_seq_midi_event ir_sony_decoder ir_jvc_decoder saa7134 v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 psmouse serio_raw ir_rc6_decoder snd_pcm snd_seq lp shpchp eeprom_93cx6 btusb snd_timer snd_seq_device videobuf_dma_sg ir_rc5_decoder snd videobuf_core ir_nec_decoder ir_common ir_core tveeprom soundcore edac_core bluetooth snd_page_alloc parport i2c_nforce2 k8temp edac_mce_amd usbhid hid btrfs zlib_deflate crc32c libcrc32c sata_nv forcedeth pata_amd
[  601.632319]
[ 601.632335] Pid: 2928, comm: cat Not tainted 2.6.36-rc3-00185-gd56557a #2 KN9 Series(NF-CK804)/Unknow [ 601.632368] RIP: 0010:[<ffffffffa00f43b5>] [<ffffffffa00f43b5>] show_protocols+0x25/0x120 [ir_core]
[  601.632404] RSP: 0018:ffff88007bb93e38  EFLAGS: 00010282
[ 601.632423] RAX: ffff88007bb6e000 RBX: ffffffffa00f5ee0 RCX: ffffffffa00f4390 [ 601.632444] RDX: 0000000000000000 RSI: ffffffffa00f5ee0 RDI: ffff88007bb6e000 [ 601.632465] RBP: ffff88007bb93e68 R08: ffff88007bb6e010 R09: ffffffff8164ab40 [ 601.632486] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88007c928000 [ 601.632507] R13: 0000000000008000 R14: 000000000246d000 R15: ffff88007c8798a0 [ 601.632529] FS: 00007fe7aa26c700(0000) GS:ffff880001e00000(0000) knlGS:0000000000000000
[  601.632561] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 601.632580] CR2: 0000000000000000 CR3: 000000007b19f000 CR4: 00000000000006f0 [ 601.632601] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 601.632623] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 601.632644] Process cat (pid: 2928, threadinfo ffff88007bb92000, task ffff88007bcd2dc0)
[  601.632675] Stack:
[ 601.632689] 0000000000000000 ffffffffa00f5ee0 ffff88007bb93f48 0000000000008000 [ 601.632713] <0> 000000000246d000 ffff88007c8798a0 ffff88007bb93e98 ffffffff813816e7 [ 601.632750] <0> ffff88007bb93e88 ffffffff8110681e ffff88007bb93e98 ffff88007c8798c0
[  601.632797] Call Trace:
[  601.632819]  [<ffffffff813816e7>] dev_attr_show+0x27/0x50
[  601.632842]  [<ffffffff8110681e>] ? __get_free_pages+0xe/0x50
[  601.632864]  [<ffffffff811bf5b1>] sysfs_read_file+0xd1/0x1c0
[  601.632886]  [<ffffffff81152f15>] vfs_read+0xc5/0x190
[  601.632906]  [<ffffffff81153551>] sys_read+0x51/0x90
[  601.632928]  [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[ 601.632947] Code: eb 04 90 90 90 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 0f 1f 44 00 00 49 89 d4 e8 12 0e 29 e1 48 8b 90 90 02 00 00 <44> 8b 0a 45 85 c9 0f 85 af 00 00 00 4c 8b a8 70 02 00 00 48 8b
[  601.633112] RIP  [<ffffffffa00f43b5>] show_protocols+0x25/0x120 [ir_core]
[  601.633136]  RSP <ffff88007bb93e38>
[  601.633152] CR2: 0000000000000000
[  601.633448] ---[ end trace 0dbd0f2ee839a90b ]---

A similar problem exists in store_protocols and makes lircd oops and die at startup.

+               enabled = ir_dev->rc_tab.ir_type;
+               allowed = ir_dev->props->allowed_protos;
+       } else {
+               enabled = ir_dev->raw->enabled_protocols;

ir_dev->raw is also null. If I check these pointers before using them, and bail out if both are null, then I get a working lircd, but of course the file /sys/devices/virtual/rc/rc0/protocols no longer does anything. On 2.6.35.4, the system never creates the /sys/class/rc/rc0/current_protocol file. Is it the case that the 'protocols' file should never appear, because my card can't support this feature?

Brian

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to