- 01 11月, 2011 3 次提交
-
-
由 Paul Gortmaker 提交于
A pending cleanup will mean that module.h won't be implicitly everywhere anymore. Make sure the modular drivers in clocksource are actually calling out for <module.h> explicitly in advance. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
由 Paul Gortmaker 提交于
These two macros were in module.h but now module.h is no longer sprayed across every source file imaginable, so the users need to expicitly call out their use of them. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
由 Stephen Rothwell 提交于
To fix: drivers/media/rc/ir-raw.c: In function 'init_decoders': drivers/media/rc/ir-raw.c:354:2: error: implicit declaration of function 'request_module' Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
- 11 9月, 2011 1 次提交
-
-
由 Jarod Wilson 提交于
The nuvoton-cir driver was storing up consecutive pulse-pulse and space-space samples internally, for no good reason, since ir_raw_event_store_with_filter() already merges back to back like samples types for us. This should also fix a regression introduced late in 3.0 that related to a timeout change, which actually becomes correct when coupled with this change. Tested with RC6 and RC5 on my own nuvoton-cir hardware atop vanilla 3.0.0, after verifying quirky behavior in 3.0 due to the timeout change. Reported-by: NStephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: stable@vger.kernel.org Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 29 7月, 2011 1 次提交
-
-
由 Stephen Rothwell 提交于
drivers/media/rc/ir-mce_kbd-decoder.c:446:16: error: expected declaration specifiers or '...' before string constant drivers/media/rc/ir-mce_kbd-decoder.c:446:1: warning: data definition has no type or storage class drivers/media/rc/ir-mce_kbd-decoder.c:446:1: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE' drivers/media/rc/ir-mce_kbd-decoder.c:446:16: warning: function declaration isn't a prototype drivers/media/rc/ir-mce_kbd-decoder.c:447:15: error: expected declaration specifiers or '...' before string constant drivers/media/rc/ir-mce_kbd-decoder.c:447:1: warning: data definition has no type or storage class drivers/media/rc/ir-mce_kbd-decoder.c:447:1: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR' drivers/media/rc/ir-mce_kbd-decoder.c:447:15: warning: function declaration isn't a prototype drivers/media/rc/ir-mce_kbd-decoder.c:448:20: error: expected declaration specifiers or '...' before string constant drivers/media/rc/ir-mce_kbd-decoder.c:448:1: warning: data definition has no type or storage class drivers/media/rc/ir-mce_kbd-decoder.c:448:1: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION' drivers/media/rc/ir-mce_kbd-decoder.c:448:20: warning: function declaration isn't a prototype Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 28 7月, 2011 9 次提交
-
-
由 Jarod Wilson 提交于
This is admittedly a bit of a hack, but if we change our timeout value to something longer and fudge our synthesized trailing space sample based on the initial pulse sample, rc-core decode continues to work just fine with both rc-6 and rc-5, and now lirc userspace decode shows proper repeats for both of those protocols as well. Also tested NEC successfully with both decode options. We do still need a reset timer callback using the hardware's timeout value to make sure we actually process samples correctly, regardless of our somewhat hacky timeout and synthesized trailer above. This also adds a missing del_timer_sync call to the module unload path. CC: Chris Dodge <chris@redrat.co.uk> CC: Andrew Vincer <andrew.vincer@redrat.co.uk> CC: Stephen Cox <scox_nz@yahoo.com> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Trying to cap duration before multiplying it was obviously wrong. CC: Chris Dodge <chris@redrat.co.uk> CC: Andrew Vincer <andrew.vincer@redrat.co.uk> CC: Stephen Cox <scox_nz@yahoo.com> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
We already add a trailing space, this wasn't doing anything useful, and actually confused lirc userspace a bit. Rip it out. CC: Chris Dodge <chris@redrat.co.uk> CC: Andrew Vincer <andrew.vincer@redrat.co.uk> CC: Stephen Cox <scox_nz@yahoo.com> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
This is a custom IR protocol decoder, for the RC-6-ish protocol used by the Microsoft Remote Keyboard, apparently developed internally at Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and transceiver requirements and specifications document, which also touches on this IR keyboard/mouse device. Its a standard keyboard with embedded thumb stick mouse pointer and mouse buttons, along with a number of media keys. The media keys are standard RC-6, identical to the signals from the stock MCE remotes, and will be handled as such. The keyboard and mouse signals will be decoded and delivered to the system by an input device registered specifically by this driver. Successfully tested with multiple mceusb-driven transceivers, as well as with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware with enough sampling resolution should be able to use this decoder, nothing about it is at all receiver-hardware-specific. This work is inspired by lirc_mod_mce: The documentation there and code aided in understanding and decoding the protocol, but the bulk of the code is actually borrowed more from the existing in-kernel decoders than anything. I did recycle the keyboard keycode table, a few defines, and some of the keyboard and mouse data parsing bits from lirc_mod_mce though. Special thanks to James Meyer for providing the hardware, and being patient with me as I took forever to get around to writing this. callback routine to ensure we don't get any stuck keys, and used symbolic names for the keytable. Also cc'ing Florian this time, who I believe is the original mod-mce author... CC: Florian Demski <fdemski@users.sourceforge.net> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Microsoft's Windows Media Center specification and requirements doc from 2011.03.18 now refers to the former Power Toggle button as the Sleep Toggle, and recommends using a new moon sleep icon for it. Its the same key, but its apparently always been meant to put the system to sleep, not power it off. Adjust accordingly. While we're here, lets also remove the duplicate KEY_PLAYPAUSE entry. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 David Härdeman 提交于
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: NDavid Härdeman <david@hardeman.nu> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 David Härdeman 提交于
The conversion of winbond-cir to use rc-core seems to have missed a a few bits and pieces which were in my local tree. Kudos to Juan Jesús García de Soria Lucena <skandalfo@gmail.com> for noticing. [mchehab@redhat.com: fix two UTF-8 violations] Signed-off-by: NDavid Härdeman <david@hardeman.nu> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Dan Carpenter 提交于
In the original code, if the allocation failed we dereference "rr3" when it was NULL. Acked-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Dan Carpenter 提交于
If change_protocol() fails and we goto out_raw, then it calls unlock twice. I noticed that the other time we called change_protocol() we held the &dev->lock, so I changed it to hold it here too. Reviewed-by: NJarod Wilson <jarod@redhat.com> Acked-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 12 7月, 2011 3 次提交
-
-
由 Jarod Wilson 提交于
The nuvoton-cir inherited an insanely low idle timeout value from the mceusb driver. We're fixing mceusb, should fix this driver too. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Rafi Rubin 提交于
This matches the typical timeout advertised by hardware, once we're actually interpreting it correctly. Signed-off-by: NRafi Rubin <rafi@seas.upenn.edu> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Rafi Rubin 提交于
Unit missmatch in mceusb_handle_command. It should be converting to us, not 1/10th of ms. mceusb_dev_printdata 100us/ms -> 1000us/ms Alter format of fix slightly and update comment to match proper reality. Signed-off-by: NRafi Rubin <rafi@seas.upenn.edu> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 02 7月, 2011 6 次提交
-
-
由 Jarod Wilson 提交于
Due to commit cdda911c, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. For example, take an mceusb transceiver with a default rc6 keymap. Press buttons on an rc5 remote while monitoring with ir-keytable, and you'll see nothing. Now press a button on the rc6 remote matching the keymap. You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6 key spit out all at the same time. Pressing and holding a button on a remote we do have a keymap for also works rather unreliably right now, due to repeat events also happening without a call to input_sync (we bail from ir_do_keydown before getting to the point where it calls input_sync). Easy fix though, just add two strategically placed input_sync calls right after our input_event calls for EV_MSC, and all is well again. Technically, we probably should have been doing this all along, its just that it never caused any functional difference until the referenced change went into the input layer. input_sync once per IR signal. There was another hidden bug in the code where we were calling input_report_key using last_keycode instead of our just discovered keycode, which manifested with the reordering of calling input_report_key and setting last_keycode. Reported-by: NStephan Raue <sraue@openelec.tv> CC: Stephan Raue <sraue@openelec.tv> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Jeff Brown <jeffbrown@android.com> Acked-by: NDmitry Torokhov <dtor@mail.ru> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
While 0xffdc devices have their IR protocol hard-coded into the firmware of the device, we have no known way of telling what it is if we don't have the device's config byte already in the driver. Unknown devices default to the imon native protocol, but might actually be rc6, so we should set the driver up such that the user can load the rc6 keytable from userspace and still have a working device ahead of its config byte being added to the driver. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Another device with the 0xffdc device id, this one with 0x7e in the config byte. Its an iMON VFD + RC6 IR, in a CoolerMaster 260 case. Reported-by: NFilip Streibl <filip@streibl.cz> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
With hardware that has to use ir_raw_event_store_edge to collect IR sample durations, we were not doing an event reset unless IR_MAX_DURATION had passed. That's around 4 seconds. So if someone presses up, then down, with less than 4 seconds in between, they'd get the initial up, then up and down upon pressing down. To fix this, I've lowered the "send a reset event" logic's threshold to the input device's REP_DELAY (defaults to 500ms), and with an saa7134-based GPIO-driven IR receiver in a Hauppauge HVR-1150, I get *much* better behavior out of the remote now. Special thanks to Devin for providing the hardware to investigate this issue. CC: stable@kernel.org CC: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Both consumers of RC_MAP_PINNACLE_PCTV_HD send along full RC-5 scancodes, so this update makes this keymap actually *have* full scancodes, heisted from rc-dib0700-rc5.c. This should fix out of the box remote functionality for the Pinnacle PCTV HD 800i (cx88 pci card) and PCTV HD Pro 801e (em28xx usb stick). CC: stable@kernel.org Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Thanks to the intrepid testing and debugging of Matthijs van Drunen, it was uncovered that at least some variants of the ITE8709 need to use pnp resource 2, rather than 0, for things to function properly. Resource 0 has a length of only 1, and if you try to bypass the pnp_port_len check and use it anyway (with either a length of 1 or 2), the system in question's trackpad ceased to function. The circa lirc 0.8.7 lirc_ite8709 driver used resource 2, but the value was (amusingly) changed to 0 by way of a patch from ITE themselves, so I don't know if there may be variants where 0 actually *is* correct, but at least in this case and in the original lirc_ite8709 driver author's case, it sure looks like 2 is the right value. This fix should probably be applied to all stable kernels with the ite-cir driver, lest we nuke more people's trackpads. Tested-by: Matthijs van Drunen CC: Juan Jesús García de Soria <skandalfo@gmail.com> CC: stable@kernel.org Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 20 6月, 2011 1 次提交
-
-
由 Vitaliy Ivanov 提交于
Many stupid corrections of duplicated includes based on the output of scripts/checkincludes.pl. Signed-off-by: NVitaliy Ivanov <vitalivanov@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 11 6月, 2011 9 次提交
-
-
由 Jarod Wilson 提交于
As pointed out on the lirc list by Andreas Dick, initial panel key repeat suppression wasn't working, as we had no timevals accumulated until after the first repeat. Also add a missing locking call. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Courtesy of information from Andreas Dick on the lirc list. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Hans Petter Selasky pointed out to me that we're leaking urbs when mce_async_out is called. Its used both for configuring the hardware and for transmitting IR data. In the tx case, mce_request_packet actually allocates both a urb and the transfer buffer, neither of which was being torn down. Do that in the tx callback. CC: Hans Petter Selasky <hselasky@c2i.net> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
There was a missing lock in fintek_suspend. Without the lock, its possible the system will be in the middle of receiving IR (draining the RX buffer) when we try to disable CIR interrupts. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Store the cdev pointer in struct irctl, allocated dynamically as needed, rather than having a static array. At the same time, recycle some of the saved memory to nudge the maximum number of lirc devices supported up a ways -- its not that uncommon these days, now that we have the rc-core lirc bridge driver, to see a system with at least 4 raw IR receivers. (consider a mythtv backend with several video capture devices and the possible need for IR transmit hardware). Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Aside from the initial "hey, lets make sure we've flushed any pre-existing data on the device" call to mce_sync_in, every other one of the calls was entirely superfluous. Ergo, remove them all, and rename the one and only (questionably) useful one to reflect what it really does. Verified on both gen2 and gen3 hardware to make zero difference. Well, except that you no longer get a bunch of urb submit failures from the unneeded mce_sync_in calls. Oh. And move that flush to a point *after* we've wired up the inbound urb, or it won't do squat. I have half a mind to just remove it entirely, but someone thought it was necessary at some point, and it doesn't seem to hurt, so lets leave it for the time being. This excercise took place due to insightful questions asked by Hans Petter Selasky, about the possible reuse of the inbound urb before it was actually availble by mce_sync_in, so thanks to him for motivating this cleanup. Reported-by: NHans Petter Selasky <hselasky@c2i.net> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
There's an SMK-device-id remote kit from I-O Data avaiable primarily in Japan, which appears to have no tx hardware, but has rx functionality that works with the mceusb driver by simply adding its device ID. Reported-by: NJeremy Kwok <jeremykwok@desu.ca> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Using dev_dbg is more complexity than many users are able to deal with. Make it easier to get debug spew feedback from them by adding an mce_dbg printk macro that spews using dev_info when debug=1 is set for the mceusb module. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 26 5月, 2011 2 次提交
-
-
由 Malcolm Priestley 提交于
driver to use dvb-usb-remote. The remote(s) generates 24 bit NEC codes, lme2510 keymaps redefined. Other minor fixes fix le warning. make sure frontend is detached on firmware change. Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
This is a new driver for the Fintek LPC SuperIO CIR function, in the Fintek F71809 chip. Hardware and datasheets were provided by Fintek, so thanks go to them for supporting this effort. This driver started out as a copy of the nuvoton-cir driver, and was then modified as needed for the Fintek chip. The two share many similaries, though the buffer handling for the Fintek chip is actually nearly identical to the mceusb buffer handling, so the parser routine is almost a drop-in copy of the mceusb buffer parser (a candidate for being abstracted out into shared code at some point). This initial code drop *only* supports receive, but the hardware does support transmit as well. I really haven't even started to look at what's required, but my guess is that its also pretty similar to mceusb. Most people are probably only really interested in RX anyway though, so I think its good to get this out there even with only RX. (Nb: there are also Fintek-made mceusb receivers, which presumably, this chip shares CIR hardware with). This hardware can be found on at least Jetway NC98 boards and derivative systems, and likely others as well. Functionality was tested with an NC98 development board, in-kernel decode of RC6 (mce), RC5 (hauppauge) and NEC-ish (tivo) remotes all successful, as was lirc userspace decode of the RC6 remote. CC: Aaron Huang <aaron_huang@fintek.com.tw> CC: Tom Tsai <tom_tsai@fintek.com.tw> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 21 5月, 2011 5 次提交
-
-
由 Mauro Carvalho Chehab 提交于
The default REP_PERIOD is 33 ms. This doesn't make sense for IR's, as, in general, an IR repeat scancode is provided at every 110/115ms, depending on the RC protocol. So, increase its default, to do a better job avoiding ghost repeat events. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com> Acked-by: NJarod Wilson <jarod@redhat.com>
-
由 Julia Lawall 提交于
ictx->touch is intialied in imon_init_intf1, to the result of calling the function that contains this code. Thus, in this code, input_free_device should be called on touch itself. A simplified version of the semantic match that finds this problem is: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ local idexpression struct input_dev * x; expression ra,rr; position p1,p2; @@ x = input_allocate_device@p1(...) ... when != x = rr when != input_free_device(x,...) when != if (...) { ... input_free_device(x,...) ...} if(...) { ... when != x = ra when forall when != input_free_device(x,...) \(return <+...x...+>; \| return@p2...; \) } @script:python@ p1 << r.p1; p2 << r.p2; @@ cocci.print_main("input_allocate_device",p1) cocci.print_secs("input_free_device",p2) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
This is a new rc-core device driver for the IR transceivers made by RedRat Ltd. (http://redrat.co.uk/). It started out life as an out-of-lirc-tree lirc driver, maintained in its own repo on sourceforge, by Stephen Cox. He started porting it to what was then ir-core, and I finally picked it up about two week ago and did a fairly large overhaul on it, and its now into a state where I'm fairly comfortable submitting it here for review and inclusion in the kernel. I'm claiming authorship of this driver, since while it started out as Stephen's work, its definitely a derivative work now, at 876 lines added and 1698 lines removed since grabbing it from sourceforge. Stephen's name is retained as secondary author though, and credited in the headers. Those interested in seeing how the changes evolved can (at least for now) look at this branch in my git tree: http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/redrat3 That won't be around forever though, and I'm doing this as a single commit to go into mainline. Anyway... I've successfully tested in-kernel decode of rc5, rc6 and nec remotes, as well as lirc userspace decode of rc5 and rc6. There are still some quirks here to sort out with rc5 lirc userspace decode, but I'm working with the RedRat folks themselves to figure out what's going on there (rc5 lirc decode works, but you only get an event on key release -- in-kernel rc5 decode behaves perfectly fine). Note that lirc decode of rc6 is working perfectly. Transmit is also working, tested by pointing the redrat3 at an mceusb transceiver, which happily picked up the transmitted signals and properly decoded them. There's no default remote for this hardware, so its somewhat arbitrarily set to use the Hauppauge RC5 keymap by default. Easily changed out by way of ir-keytable and irrelevant if you're using lircd for decode. CC: Chris Dodge <chris@redrat.co.uk> CC: Andrew Vincer <Andrew.Vincer@redrat.co.uk> CC: Stephen Cox <scox_nz@yahoo.com> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
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: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-