From: Juan J. G. de S. L. <ska...@gm...> - 2011-03-29 19:56:42
|
Hi, Dmitrii, Jarod... I'll put the lirc list in copy of this, if you don't mind, Dmitrii... :-) I've been debugging a little bit the problem that Dmitrii is having with lirc 0.9.0 and 2.6.37.4. I've been able to reproduce it with 2.6.35 from Ubuntu 10.10: [ 1617.821085] divide error: 0000 [#1] SMP [ 1617.821104] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq [ 1617.821114] CPU 1 [ 1617.821120] Modules linked in: lirc_wpc8769l lirc_dev binfmt_misc parport_pc ppdev joydev arc4 snd_hda_codec_atihdmi fglrx(P) snd_hda_codec_realtek mxl5005s snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer ath9k snd_seq_device zl10353 ath9k_common ath9k_hw ath mac80211 dvb_usb_ce6230 uvcvideo snd dvb_usb videodev v4l1_compat cfg80211 v4l2_compat_ioctl32 dvb_core edac_core soundcore i2c_piix4 k10temp snd_page_alloc psmouse serio_raw edac_mce_amd led_class shpchp video output lp parport usb_storage ahci pata_atiixp atl1e libahci [last unloaded: lirc_dev] [ 1617.821271] [ 1617.821285] Pid: 8091, comm: xmode2 Tainted: P 2.6.35-28-generic #49-Ubuntu Mantasta /Aspire 6530G [ 1617.821298] RIP: 0010:[<ffffffffa00fb4cd>] [<ffffffffa00fb4cd>] lirc_dev_fop_read+0xfd/0x504 [lirc_dev] [ 1617.821330] RSP: 0018:ffff88008d5c5e38 EFLAGS: 00010246 [ 1617.821340] RAX: 0000000000000004 RBX: ffff88013182af00 RCX: 0000000000000000 [ 1617.821350] RDX: 0000000000000000 RSI: 00000000000080d0 RDI: 0000000000000001 [ 1617.821360] RBP: ffff88008d5c5ee8 R08: 0000000000000000 R09: ffff880151c30000 [ 1617.821370] R10: 00007fff91ca4480 R11: 0000000000000246 R12: ffff88013f15ec00 [ 1617.821380] R13: 0000000000000010 R14: 0000000000000003 R15: 0000000000000004 [ 1617.821392] FS: 00007f7d33f85760(0000) GS:ffff880001f00000(0000) knlGS:00000000f696aa90 [ 1617.821403] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1617.821413] CR2: 00007ff5d44cd000 CR3: 000000008d5d1000 CR4: 00000000000006e0 [ 1617.821423] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1617.821434] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1617.821445] Process xmode2 (pid: 8091, threadinfo ffff88008d5c4000, task ffff8801231b5b80) [ 1617.821453] Stack: [ 1617.821459] 0000000000000000 0000000000000000 ffff88008d5c5d28 ffff88008d5c5f48 [ 1617.821474] <0> ffff88013182af90 0000000000000000 00007fff91ca486c 0000000000000000 [ 1617.821490] <0> 00007f7d32361720 0000000000000000 0000000000000000 ffff8801231b5b80 [ 1617.821508] Call Trace: [ 1617.821532] [<ffffffff810572f0>] ? default_wake_function+0x0/0x20 [ 1617.821554] [<ffffffff81260466>] ? security_file_permission+0x16/0x20 [ 1617.821570] [<ffffffff811539a5>] vfs_read+0xb5/0x1a0 [ 1617.821583] [<ffffffff81153ae1>] sys_read+0x51/0x80 [ 1617.821598] [<ffffffff81165b3c>] ? sys_poll+0x7c/0x110 [ 1617.821617] [<ffffffff8100a0f2>] system_call_fastpath+0x16/0x1b [ 1617.821626] Code: e8 49 e8 48 e1 89 c2 48 c7 c0 00 fe ff ff 85 d2 75 c7 8b bb 88 00 00 00 85 ff 0f 84 57 03 00 00 8b 8b b8 00 00 00 31 d2 4c 89 f8 <48> f7 f1 48 85 d2 0f 85 a8 01 00 00 48 8b bb b0 00 00 00 48 8d [ 1617.821745] RIP [<ffffffffa00fb4cd>] lirc_dev_fop_read+0xfd/0x504 [lirc_dev] [ 1617.821765] RSP <ffff88008d5c5e38> [ 1617.821825] ---[ end trace 9ba104d6dafeedb0 ]--- This is after he modified the driver so that it'll fill in the .dev field of the lirc_driver struct (this seems to be a new requirement that the driver did not get modified to satisfy before), because it wouldn't even load otherwise: >> > driver.dev = &lirc_wpc8769l_platform_dev->dev; >> > before >> > driver.minor = lirc_register_driver(&driver); What's happening: it's a divide_by_zero error because lirc_dev seems to be reading the ir->chunk_size in lirc_dev_fop_read(): 777 if (length % ir->chunk_size) { 778 dprintk(LOGHEAD "read result = -EINVAL\n", 779 ir->d.name, ir->d.minor); And right now this ir->chunk_size field is copied from ir->buf->chunk_size in lirc_register_driver(): 384 } 385 ir->chunk_size = ir->buf->chunk_size; 386 Whereas my driver doesn't actually have a valid buffer allocated at that time. Actually it gets allocated/freed on set_use_inc() and set_use_dec() as the device is opened/closed. After moving lirc_buffer_init()/lirc_buffer_free() calls to some proper place in lirc_wpc8769l_module_init()/lirc_wpc8769l_module_exit() (that is, before/after the lirc_register_driver()/lirc_unregister_driver() calls), the driver works again. So, Jarod... Is this behavior change actually intended? I guess so, since these two commits happened on lirc_serial (the driver I used as a reference for writing lirc_wpc8769l): 1. Fill in dev pointer: http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=2d69a41a790ab2c006cb46811beadd132286cbd5 2. Moving buffer allocation/deallocation as explained above: http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=6b440d65b50f3d2fab0a618e7c35ee6a34cdc1e8 So... should I prepare a patch doing these two things for my driver and send it to the list? Is there any other modification required to make the driver up to date? Best regards, Juan Jesús. El día 29 de marzo de 2011 21:25, Dmitrii Khrysev <x86...@gm...> escribió: > Hi again. Than you for your response. dmesg output is in attachments. I have > no lspnp, so I can't give you it's output > You are right, I'm trying to use latest lirc 0.9 from git, seems 0.8.7 do > not support latest changes in kernel IR drivers > --- > Kernel: Linux x86nout 2.6.37.4-calculate #1 SMP PREEMPT Tue Mar 29 00:54:25 > EEST 2011 i686 Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz GenuineIntel > GNU/Linux > Distribution: Calculate linux (based on gentoo) > --- > Driver from git (not changed) > # modprobe lirc_wpc8769l > FATAL: Error inserting lirc_wpc8769l > (/lib/modules/2.6.37.4-calculate/misc/lirc_wpc8769l.ko): Input/output error > --- > With debug flag enabled: > # modprobe lirc_wpc8769l debug=1 > FATAL: Error inserting lirc_wpc8769l > (/lib/modules/2.6.37.4-calculate/misc/lirc_wpc8769l.ko): Input/output error > # dmesg > ... > lirc_wpc8769l: Found WEC1020 device via ACPI. > lirc_wpc8769l: lirc_wpc8769l device found to use 0x0600, 0x0620 I/O bases, > IRQ #4. > lirc_register_driver: dev pointer not filled in! > lirc_wpc8769l: lirc_register_driver failed! > > 2011/3/29 Juan Jesús García de Soria Lucena <ska...@gm...> >> >> Hi, Dmitrii, >> >> It's been a long time since I last used this driver on my machine, so >> it could have succumbed to bitrot... >> >> Even if your change may be perfectly fine, I'd like to have your dmesg >> without it. >> >> I guess you're using lirc 0.9.0, aren't you? >> >> I'd like to know also what's your kernel version and distribution. >> I'll try to find some time-slot to get the current lirc code to check >> whether it's still working in my machine. >> >> Also, I'd like to have the output of lspnp -v, without the driver loaded. >> >> >> Best regards, >> >> Juan Jesús. >> >> >> 2011/3/29 Dmitrii Khrysev <x86...@gm...>: >> > Ok, I have got it loaded and /dev/lirc0 created, by adding >> > driver.dev = &lirc_wpc8769l_platform_dev->dev; >> > before >> > driver.minor = lirc_register_driver(&driver); >> > Now i see next in /var/log/messages >> > Mar 29 21:05:50 x86nout kernel: put_item: 1118 callbacks suppressed >> > Mar 29 21:05:50 x86nout kernel: lirc_wpc8769l: RX buffer overrun. >> > Mar 29 21:05:50 x86nout kernel: lirc_wpc8769l: RX buffer overrun. >> > ... >> > irw and mode2 give no output >> > >> > On Tue, Mar 29, 2011 at 2:45 PM, Dmitrii Khrysev <x86...@gm...> >> > wrote: >> >> >> >> Hi, I have used your driver with older kernel and LIRC 0.8.5 >> >> Now kernel has updated with system and I can't get your driver >> >> workable. >> >> Tried latest git version of LIRC. Got IO error on modprobe. Driver has >> >> detected IR receiver but it did not loaded because of some error. I can >> >> send >> >> you dmesg message later. Pls. help >> >> -- >> >> With best regards, >> >> Khrysev Dmitry >> >> >> >> Mobile: +38 (063) 259-88-41 >> >> ICQ: 191448397 >> >> Skype: x86_demon >> >> Mail: x86...@gm... >> > >> > >> > >> > -- >> > With best regards, >> > Khrysev Dmitry >> > >> > Mobile: +38 (063) 259-88-41 >> > ICQ: 191448397 >> > Skype: x86_demon >> > Mail: x86...@gm... >> > >> >> >> >> -- >> :wq > > > > -- > With best regards, > Khrysev Dmitry > > Mobile: +38 (063) 259-88-41 > ICQ: 191448397 > Skype: x86_demon > Mail: x86...@gm... > -- :wq |
From: Jarod W. <ja...@wi...> - 2011-03-29 20:16:51
|
On Mar 29, 2011, at 3:56 PM, Juan Jesús García de Soria Lucena wrote: > Hi, Dmitrii, Jarod... > > I'll put the lirc list in copy of this, if you don't mind, Dmitrii... :-) > > > I've been debugging a little bit the problem that Dmitrii is having > with lirc 0.9.0 and 2.6.37.4. I've been able to reproduce it with > 2.6.35 from Ubuntu 10.10: > > [ 1617.821085] divide error: 0000 [#1] SMP > [ 1617.821104] last sysfs file: > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > [ 1617.821114] CPU 1 > [ 1617.821120] Modules linked in: lirc_wpc8769l lirc_dev binfmt_misc > parport_pc ppdev joydev arc4 snd_hda_codec_atihdmi fglrx(P) > snd_hda_codec_realtek mxl5005s snd_hda_intel snd_hda_codec snd_hwdep > snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer > ath9k snd_seq_device zl10353 ath9k_common ath9k_hw ath mac80211 > dvb_usb_ce6230 uvcvideo snd dvb_usb videodev v4l1_compat cfg80211 > v4l2_compat_ioctl32 dvb_core edac_core soundcore i2c_piix4 k10temp > snd_page_alloc psmouse serio_raw edac_mce_amd led_class shpchp video > output lp parport usb_storage ahci pata_atiixp atl1e libahci [last > unloaded: lirc_dev] > [ 1617.821271] > [ 1617.821285] Pid: 8091, comm: xmode2 Tainted: P > 2.6.35-28-generic #49-Ubuntu Mantasta /Aspire 6530G > [ 1617.821298] RIP: 0010:[<ffffffffa00fb4cd>] [<ffffffffa00fb4cd>] > lirc_dev_fop_read+0xfd/0x504 [lirc_dev] > [ 1617.821330] RSP: 0018:ffff88008d5c5e38 EFLAGS: 00010246 > [ 1617.821340] RAX: 0000000000000004 RBX: ffff88013182af00 RCX: 0000000000000000 > [ 1617.821350] RDX: 0000000000000000 RSI: 00000000000080d0 RDI: 0000000000000001 > [ 1617.821360] RBP: ffff88008d5c5ee8 R08: 0000000000000000 R09: ffff880151c30000 > [ 1617.821370] R10: 00007fff91ca4480 R11: 0000000000000246 R12: ffff88013f15ec00 > [ 1617.821380] R13: 0000000000000010 R14: 0000000000000003 R15: 0000000000000004 > [ 1617.821392] FS: 00007f7d33f85760(0000) GS:ffff880001f00000(0000) > knlGS:00000000f696aa90 > [ 1617.821403] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 1617.821413] CR2: 00007ff5d44cd000 CR3: 000000008d5d1000 CR4: 00000000000006e0 > [ 1617.821423] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 1617.821434] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 1617.821445] Process xmode2 (pid: 8091, threadinfo ffff88008d5c4000, > task ffff8801231b5b80) > [ 1617.821453] Stack: > [ 1617.821459] 0000000000000000 0000000000000000 ffff88008d5c5d28 > ffff88008d5c5f48 > [ 1617.821474] <0> ffff88013182af90 0000000000000000 00007fff91ca486c > 0000000000000000 > [ 1617.821490] <0> 00007f7d32361720 0000000000000000 0000000000000000 > ffff8801231b5b80 > [ 1617.821508] Call Trace: > [ 1617.821532] [<ffffffff810572f0>] ? default_wake_function+0x0/0x20 > [ 1617.821554] [<ffffffff81260466>] ? security_file_permission+0x16/0x20 > [ 1617.821570] [<ffffffff811539a5>] vfs_read+0xb5/0x1a0 > [ 1617.821583] [<ffffffff81153ae1>] sys_read+0x51/0x80 > [ 1617.821598] [<ffffffff81165b3c>] ? sys_poll+0x7c/0x110 > [ 1617.821617] [<ffffffff8100a0f2>] system_call_fastpath+0x16/0x1b > [ 1617.821626] Code: e8 49 e8 48 e1 89 c2 48 c7 c0 00 fe ff ff 85 d2 > 75 c7 8b bb 88 00 00 00 85 ff 0f 84 57 03 00 00 8b 8b b8 00 00 00 31 > d2 4c 89 f8 <48> f7 f1 48 85 d2 0f 85 a8 01 00 00 48 8b bb b0 00 00 00 > 48 8d > [ 1617.821745] RIP [<ffffffffa00fb4cd>] lirc_dev_fop_read+0xfd/0x504 [lirc_dev] > [ 1617.821765] RSP <ffff88008d5c5e38> > [ 1617.821825] ---[ end trace 9ba104d6dafeedb0 ]--- > > > This is after he modified the driver so that it'll fill in the .dev > field of the lirc_driver struct (this seems to be a new requirement > that the driver did not get modified to satisfy before), because it > wouldn't even load otherwise: > >>>> driver.dev = &lirc_wpc8769l_platform_dev->dev; >>>> before >>>> driver.minor = lirc_register_driver(&driver); > > What's happening: it's a divide_by_zero error because lirc_dev seems > to be reading the ir->chunk_size in lirc_dev_fop_read(): > > 777 if (length % ir->chunk_size) { > 778 dprintk(LOGHEAD "read result = -EINVAL\n", > 779 ir->d.name, ir->d.minor); > > And right now this ir->chunk_size field is copied from > ir->buf->chunk_size in lirc_register_driver(): > > 384 } > 385 ir->chunk_size = ir->buf->chunk_size; > 386 > > Whereas my driver doesn't actually have a valid buffer allocated at > that time. Actually it gets allocated/freed on set_use_inc() and > set_use_dec() as the device is opened/closed. > > After moving lirc_buffer_init()/lirc_buffer_free() calls to some > proper place in > lirc_wpc8769l_module_init()/lirc_wpc8769l_module_exit() (that is, > before/after the lirc_register_driver()/lirc_unregister_driver() > calls), the driver works again. > > So, Jarod... > > Is this behavior change actually intended? I guess so, since these two > commits happened on lirc_serial (the driver I used as a reference for > writing lirc_wpc8769l): > > > 1. Fill in dev pointer: > > http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=2d69a41a790ab2c006cb46811beadd132286cbd5 This one was definitely intended, as the dev pointer gets used all over the place now for debug spew in both device-specific drivers and in lirc_dev. > 2. Moving buffer allocation/deallocation as explained above: > > http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=6b440d65b50f3d2fab0a618e7c35ee6a34cdc1e8 Less clear on this one... I think there were more fine-grained commits either in my pre-merge kernel tree or in the staging tree, which all got lumped together in lirc git when I did a resync... I do think it was for good reason at some point though. :) > So... should I prepare a patch doing these two things for my driver > and send it to the list? Is there any other modification required to > make the driver up to date? Sounds like that's probably about it for now. Somehow, I neglected to include this driver in the upstream kernel staging submission, and thus, it doesn't get much attention -- most of my focus has been on gradual clean-ups of the drivers in the kernel, with occasional efforts to bring those changes into the lirc git tree. Ultimately, what would be ideal is a rewrite of the driver for rc-core, which is still the goal for all the drivers in the kernel staging area, but it definitely requires a person with the motivation (and probably the hardware) to do it... ;) -- Jarod Wilson ja...@wi... |
From: Juan J. G. de S. L. <ska...@gm...> - 2011-03-29 20:57:19
|
Hi again :-) El día 29 de marzo de 2011 22:16, Jarod Wilson <ja...@wi...> escribió: >> 1. Fill in dev pointer: >> >> http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=2d69a41a790ab2c006cb46811beadd132286cbd5 > > This one was definitely intended, as the dev pointer gets used all > over the place now for debug spew in both device-specific drivers and > in lirc_dev. That's sensible. >> 2. Moving buffer allocation/deallocation as explained above: >> >> http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=6b440d65b50f3d2fab0a618e7c35ee6a34cdc1e8 > > Less clear on this one... I think there were more fine-grained commits > either in my pre-merge kernel tree or in the staging tree, which all > got lumped together in lirc git when I did a resync... I do think it > was for good reason at some point though. :) Not a problem anyway. >> So... should I prepare a patch doing these two things for my driver >> and send it to the list? Is there any other modification required to >> make the driver up to date? > > Sounds like that's probably about it for now. Somehow, I neglected to > include this driver in the upstream kernel staging submission, and thus, > it doesn't get much attention -- most of my focus has been on gradual > clean-ups of the drivers in the kernel, with occasional efforts to bring > those changes into the lirc git tree. Ultimately, what would be ideal > is a rewrite of the driver for rc-core, which is still the goal for all > the drivers in the kernel staging area, but it definitely requires a > person with the motivation (and probably the hardware) to do it... ;) LOL. I have the hardware, but since I have no real use for it I did not take much care of the driver either... I'll try to prepare a patch to get this legacy driver up to date, and send it to you (hopefully before the weekend). This should be enough as an interim measure. In the long term, I totally agree with you about the migration to rc-core. I'm already in talks with David Härdeman (the author of winbond-cir), since there seems to be a lot of commonality between both his WEC1022 and my WEC1020 variants. Probably I could just fold my driver onto his with a little bit of effort. In particular the NatSemi data sheet referenced in the winbond-cir source made my hardware a lot clearer for me (lirc_wpc8769l was reverse engineered). BTW, the winbond-cir driver seems to be a bitrot victim too, even while living in the media_tree repository. I had to make it fill in data->dev->driver_type, data->dev->allowed_protos and data->dev->map_name in wbcir_probe() just to get the module to load and get a /dev/lirc0 avatar. :-) Best regards, and thanks again, Juan Jesús. -- :wq |
From: Jarod W. <ja...@wi...> - 2011-03-29 22:28:19
|
On Mar 29, 2011, at 4:57 PM, Juan Jesús García de Soria Lucena wrote: ... >>> So... should I prepare a patch doing these two things for my driver >>> and send it to the list? Is there any other modification required to >>> make the driver up to date? >> >> Sounds like that's probably about it for now. Somehow, I neglected to >> include this driver in the upstream kernel staging submission, and thus, >> it doesn't get much attention -- most of my focus has been on gradual >> clean-ups of the drivers in the kernel, with occasional efforts to bring >> those changes into the lirc git tree. Ultimately, what would be ideal >> is a rewrite of the driver for rc-core, which is still the goal for all >> the drivers in the kernel staging area, but it definitely requires a >> person with the motivation (and probably the hardware) to do it... ;) > > LOL. I have the hardware, but since I have no real use for it I did > not take much care of the driver either... Heh, I know how it goes. Tons of IR receivers here, and my main mythtv box, I use a bluetooth remote and no lirc at all... > I'll try to prepare a patch to get this legacy driver up to date, and > send it to you (hopefully before the weekend). This should be enough > as an interim measure. Sounds like a plan. > In the long term, I totally agree with you about the migration to > rc-core. I'm already in talks with David Härdeman (the author of > winbond-cir), since there seems to be a lot of commonality between > both his WEC1022 and my WEC1020 variants. Probably I could just fold > my driver onto his with a little bit of effort. In particular the > NatSemi data sheet referenced in the winbond-cir source made my > hardware a lot clearer for me (lirc_wpc8769l was reverse engineered). > > BTW, the winbond-cir driver seems to be a bitrot victim too, even > while living in the media_tree repository. I had to make it fill in > data->dev->driver_type, data->dev->allowed_protos and > data->dev->map_name in wbcir_probe() just to get the module to load > and get a /dev/lirc0 avatar. :-) Ah, I think David wrote most of winbond-cir before the lirc bridge driver existed, and probably doesn't use lirc with winbond-cir at all. We should definitely get that taken care of upstream, please do send a patch to linux-media. -- Jarod Wilson ja...@wi... |
From: Juan J. G. de S. L. <ska...@gm...> - 2011-03-30 18:59:02
|
Hi, Jarod. El mar, 29-03-2011 a las 18:28 -0400, Jarod Wilson escribió: > On Mar 29, 2011, at 4:57 PM, Juan Jesús García de Soria Lucena wrote: > > I'll try to prepare a patch to get this legacy driver up to date, and > > send it to you (hopefully before the weekend). This should be enough > > as an interim measure. > > Sounds like a plan. Find the patch inline :-) (I hope my new Evolution+GMail setup doesn't break it; please tell me if it does...) Best regards, Juan Jesús. ------------ diff -ur lirc-0.9.0-orig/drivers/lirc_wpc8769l/lirc_wpc8769l.c lirc-0.9.0/drivers/lirc_wpc8769l/lirc_wpc8769l.c --- lirc-0.9.0-orig/drivers/lirc_wpc8769l/lirc_wpc8769l.c 2011-03-25 23:28:18.000000000 +0100 +++ lirc-0.9.0/drivers/lirc_wpc8769l/lirc_wpc8769l.c 2011-03-30 20:47:18.000000000 +0200 @@ -816,10 +816,6 @@ /* Reset last timeout value. */ lastus = 0; - /* Init the read buffer. */ - if (lirc_buffer_init(&rbuf, sizeof(lirc_t), RBUF_LEN) < 0) - return -ENOMEM; - /* Acquire the IRQ. */ result = request_irq(irq, irq_handler, IRQF_DISABLED | IRQF_SHARED, @@ -863,9 +859,6 @@ /* Free the IRQ. */ free_irq(irq, THIS_MODULE); dprintk("Freed IRQ %d\n", irq); - - /* Free the RX buffer. */ - lirc_buffer_free(&rbuf); } static struct lirc_driver driver = { @@ -1065,19 +1058,29 @@ /* Do load-time checks. */ wpc8769l_power_up_and_check_if_we_woke_us_up(); + /* Init the read buffer. */ + if (lirc_buffer_init(&rbuf, sizeof(lirc_t), RBUF_LEN) < 0) { + rc = -ENOMEM; + goto exit_platform_exit; + } + /* Configure the driver hooks. */ driver.features = LIRC_CAN_REC_MODE2; + driver.dev = &lirc_wpc8769l_platform_dev->dev; driver.minor = lirc_register_driver(&driver); if (driver.minor < 0) { eprintk("lirc_register_driver failed!\n"); rc = -EIO; - goto exit_platform_exit; + goto exit_release_buffer; } iprintk("Driver loaded.\n"); return 0; /* Everything OK. */ +exit_release_buffer: + lirc_buffer_free(&rbuf); + exit_platform_exit: lirc_wpc8769l_platform_exit(); @@ -1095,12 +1098,15 @@ static void __exit lirc_wpc8769l_module_exit(void) { - /* Unregister the platform driver and device. */ - lirc_wpc8769l_platform_exit(); - /* Unregister the LIRC driver. */ lirc_unregister_driver(driver.minor); + /* Free the buffer. */ + lirc_buffer_free(&rbuf); + + /* Unregister the platform driver and device. */ + lirc_wpc8769l_platform_exit(); + /* Release the second range. */ if (baseport2) release_region(baseport2, WPC8769L_IO_REGION_2_SIZE); |
From: Jarod W. <ja...@wi...> - 2011-03-30 20:47:49
|
On Mar 30, 2011, at 2:58 PM, Juan Jesús García de Soria Lucena wrote: > Hi, Jarod. > > El mar, 29-03-2011 a las 18:28 -0400, Jarod Wilson escribió: >> On Mar 29, 2011, at 4:57 PM, Juan Jesús García de Soria Lucena wrote: >>> I'll try to prepare a patch to get this legacy driver up to date, and >>> send it to you (hopefully before the weekend). This should be enough >>> as an interim measure. >> >> Sounds like a plan. > > Find the patch inline :-) > > (I hope my new Evolution+GMail setup doesn't break it; please tell me if > it does...) Committed and pushed, wasn't broken. Thanks much! -- Jarod Wilson ja...@wi... |