From: Paul B. <pa...@in...> - 2011-03-19 10:43:01
|
Hi, I have a problem with lirc. Environment: linux kernel 2.6.38, latest lirc from git, irmate-210 at com-port. Lirc's modules were compiled and loaded (lirc_dev, lirc_sir) ok (after "setserial /dev/ttyS0 uart none" command), /dev/lirc0 was created but is not accessible (device busy). Lamp on IR-reciever is answering to signals from remote-control. from dmesg: [ 5115.529538] lirc_dev: IR Remote Control driver registered, major 61 [ 5131.597454] lirc_dev: lirc_register_driver: sample_rate: 0 [ 5131.597592] lirc_sir: I/O port 0x02f8, IRQ 3. [ 5131.598006] lirc_sir: 0x10 [ 5131.651867] lirc_sir: Installed. Mode2 program says that lirc0 is used by someone, but fuser finds nothing: pashgan@wing$ sudo ./tools/mode2 -d /dev/lirc0 mode2: could not open /dev/lirc0 mode2: default_init(): Device or resource busy pashgan@wing$ sudo fuser -v /dev/lirc0 pashgan@wing$ What should I do to get it to work? |
From: Jarod W. <ja...@wi...> - 2011-03-23 15:42:26
|
On Mar 19, 2011, at 6:42 AM, Paul Bordukoff wrote: > Hi, I have a problem with lirc. Environment: linux kernel 2.6.38, latest lirc from git, irmate-210 at com-port. Lirc's modules were compiled and loaded (lirc_dev, lirc_sir) ok (after "setserial /dev/ttyS0 uart none" command), /dev/lirc0 was created but is not accessible (device busy). Lamp on IR-reciever is answering to signals from remote-control. > > from dmesg: > [ 5115.529538] lirc_dev: IR Remote Control driver registered, major 61 > [ 5131.597454] lirc_dev: lirc_register_driver: sample_rate: 0 > [ 5131.597592] lirc_sir: I/O port 0x02f8, IRQ 3. > [ 5131.598006] lirc_sir: 0x10 > [ 5131.651867] lirc_sir: Installed. > > Mode2 program says that lirc0 is used by someone, but fuser finds nothing: > pashgan@wing$ sudo ./tools/mode2 -d /dev/lirc0 > mode2: could not open /dev/lirc0 > mode2: default_init(): Device or resource busy > pashgan@wing$ sudo fuser -v /dev/lirc0 > pashgan@wing$ > > What should I do to get it to work? Well, for one, you're not running the latest lirc_sir or lirc_dev from git, since its reporting major 61. And lirc_sir is a bit of a train wreck, needs to be compiled for your specific device, so make sure you're actually compiling it for the right one. -- Jarod Wilson ja...@wi... |
From: Paul B. <pa...@in...> - 2011-03-24 16:15:24
|
Wed, 23 Mar 2011 11:13:39 -0400 Jarod Wilson <ja...@wi...>: > Well, for one, you're not running the latest lirc_sir or lirc_dev from > git, since its reporting major 61. I have recieved the source from git://lirc.git.sourceforge.net/gitroot/lirc/lirc through the "git clone" command. Is this a wrong place? > And lirc_sir is a bit of a train > wreck, needs to be compiled for your specific device, so make sure > you're actually compiling it for the right one. Yes, I have compiled it for Irmate 210. My .setup.config: LIRC_DRIVER=tekram LIRC_PORT=0x2f8 LIRC_IRQ=3 IRTTY=none DRIVER_PARAM_TYPE=com DRIVER_PARAMETER=com2 SOFT_CARRIER=on TRANSMITTER=on IGOR=off TIMER=65536 X11_WINDOWS=off DEBUG=on NO_DAEMONIZE=off NO_LONG_CODES=off USE_SYSLOG=off DYNCODES=off |
From: Jarod W. <ja...@wi...> - 2011-03-24 19:16:42
|
On Mar 24, 2011, at 12:15 PM, Paul Bordukoff wrote: > Wed, 23 Mar 2011 11:13:39 -0400 Jarod Wilson <ja...@wi...>: > >> Well, for one, you're not running the latest lirc_sir or lirc_dev from >> git, since its reporting major 61. > > I have recieved the source from git://lirc.git.sourceforge.net/gitroot/lirc/lirc through the "git clone" command. Is this a wrong place? Nope, that's the right place, and while you may have built and installed bits from there, I'm positive that's not what you're actually seeing load on your system. chardev 61 went away quite a few months ago. We use a dynamic miscdev now, which typically ends up being something in the high 240s or low 250s. Look in your kernel tree, see if there isn't another lirc_dev.ko and lirc_sir.ko. >> And lirc_sir is a bit of a train >> wreck, needs to be compiled for your specific device, so make sure >> you're actually compiling it for the right one. > > Yes, I have compiled it for Irmate 210. Okay, so you should be closer once the right lirc_dev and lirc_sir are actually loading. :) -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-03-25 20:03:02
|
Please keep the list cc'd. On Mar 25, 2011, at 11:49 AM, Paul Bordukoff wrote: > Thu, 24 Mar 2011 15:16:46 -0400 Jarod Wilson <ja...@wi...>: > >> On Mar 24, 2011, at 12:15 PM, Paul Bordukoff wrote: >> >>> Wed, 23 Mar 2011 11:13:39 -0400 Jarod Wilson <ja...@wi...>: >>> >>>> Well, for one, you're not running the latest lirc_sir or lirc_dev from >>>> git, since its reporting major 61. >>> >>> I have recieved the source from >> git://lirc.git.sourceforge.net/gitroot/lirc/lirc through the "git clone" >> command. Is this a wrong place? >> >> Nope, that's the right place, and while you may have built and >> installed bits from there, I'm positive that's not what you're >> actually seeing load on your system. chardev 61 went away quite >> a few months ago. We use a dynamic miscdev now, which typically >> ends up being something in the high 240s or low 250s. Look in >> your kernel tree, see if there isn't another lirc_dev.ko and >> lirc_sir.ko. > It is very strange because I do not have any related things with lirc in my kernel's config. The in-kernel bits would be using dynamic miscdev too, so you seem to have some old lirc cvs based bits (possibly by way of dkms or similar?) somewhere. > If I build lirc_dev and lirc_sir from kernel source I have this: > > $ modprobe lirc_dev > > (dmesg: > lirc_dev: IR Remote Control driver registered, major 253) > > $ modprobe lirc_sir > FATAL: Error inserting lirc_sir (/lib/modules/2.6.38/kernel/drivers/staging/lirc/lirc_sir.ko): Input/output error > > (dmesg: > lirc_sir: module is from the staging directory, the quality is unknown, you have been warned. > lirc_register_driver: dev pointer not filled in! > lirc_sir: init_chrdev() failed.) lirc_sir is a steaming pile. There's a patch to hopefully fix that in lirc git, but I apparently never got around to sending it upstream. -- Jarod Wilson ja...@wi... |
From: Wgge <wgg...@gm...> - 2011-03-26 09:55:20
|
Jarod Wilson <jarod@...> writes: > Nope, that's the right place, and while you may have built and > installed bits from there, I'm positive that's not what you're > actually seeing load on your system. chardev 61 went away quite > a few months ago. We use a dynamic miscdev now, which typically > ends up being something in the high 240s or low 250s. Look in > your kernel tree, see if there isn't another lirc_dev.ko and > lirc_sir.ko. Same problem seen. If chardev 61 is gone, why we see configure scripts default it to 61? --with-major=value specify the device major for the driver (61) This is also seen in gcc options when making: -DIRCTL_DEV_MAJOR=61 |
From: Paul B. <pa...@in...> - 2011-03-26 16:44:35
|
Fri, 25 Mar 2011 15:33:58 -0400 Jarod Wilson <ja...@wi...>: > Please keep the list cc'd. Ok, sorry for this. > >> Nope, that's the right place, and while you may have built and > >> installed bits from there, I'm positive that's not what you're > >> actually seeing load on your system. chardev 61 went away quite > >> a few months ago. We use a dynamic miscdev now, which typically > >> ends up being something in the high 240s or low 250s. Look in > >> your kernel tree, see if there isn't another lirc_dev.ko and > >> lirc_sir.ko. > > It is very strange because I do not have any related things with lirc in my > kernel's config. > > The in-kernel bits would be using dynamic miscdev too, so you seem > to have some old lirc cvs based bits (possibly by way of dkms or > similar?) somewhere. No, I have checked it through loading them directly by insmod from compiled git-source tree. |
From: Jarod W. <ja...@wi...> - 2011-03-29 20:08:43
|
On Mar 26, 2011, at 12:44 PM, Paul Bordukoff wrote: > Fri, 25 Mar 2011 15:33:58 -0400 Jarod Wilson <ja...@wi...>: > >> Please keep the list cc'd. > Ok, sorry for this. > >>>> Nope, that's the right place, and while you may have built and >>>> installed bits from there, I'm positive that's not what you're >>>> actually seeing load on your system. chardev 61 went away quite >>>> a few months ago. We use a dynamic miscdev now, which typically >>>> ends up being something in the high 240s or low 250s. Look in >>>> your kernel tree, see if there isn't another lirc_dev.ko and >>>> lirc_sir.ko. >>> It is very strange because I do not have any related things with lirc in my >> kernel's config. >> >> The in-kernel bits would be using dynamic miscdev too, so you seem >> to have some old lirc cvs based bits (possibly by way of dkms or >> similar?) somewhere. > > No, I have checked it through loading them directly by insmod from compiled git-source tree. See my prior reply in this thread. If you're seeing chardev 61, I'm 99% certain you're not running the latest bits. I'm not sure what might be going on here though. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-03-29 20:06:35
|
On Mar 26, 2011, at 5:37 AM, Wgge wrote: > Jarod Wilson <jarod@...> writes: > >> Nope, that's the right place, and while you may have built and >> installed bits from there, I'm positive that's not what you're >> actually seeing load on your system. chardev 61 went away quite >> a few months ago. We use a dynamic miscdev now, which typically >> ends up being something in the high 240s or low 250s. Look in >> your kernel tree, see if there isn't another lirc_dev.ko and >> lirc_sir.ko. > > Same problem seen. If chardev 61 is gone, why we see configure scripts default > it to 61? > --with-major=value specify the device major for the driver (61) > This is also seen in gcc options when making: > -DIRCTL_DEV_MAJOR=61 Unused legacy cruft. Its been unused in lirc git since October 20, 2010, via commit 2f41e817, the most relevant excerpt of which is: static int __init lirc_dev_init(void) { - if (register_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME, &lirc_dev_fops)) { - printk(KERN_ERR "lirc_dev: register_chrdev failed\n"); - goto out; - } + int retval; lirc_class = class_create(THIS_MODULE, "lirc"); if (IS_ERR(lirc_class)) { + retval = PTR_ERR(lirc_class); printk(KERN_ERR "lirc_dev: class_create failed\n"); - goto out_unregister; + goto error; + } + + retval = alloc_chrdev_region(&lirc_base_dev, 0, MAX_IRCTL_DEVICES, + IRCTL_DEV_NAME); + if (retval) { + class_destroy(lirc_class); + printk(KERN_ERR "lirc_dev: alloc_chrdev_region failed\n"); + goto error; } printk(KERN_INFO "lirc_dev: IR Remote Control driver registered, " "major %d \n", IRCTL_DEV_MAJOR); - return 0; - -out_unregister: -#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 23) - if (unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME)) - printk(KERN_ERR "lirc_dev: unregister_chrdev failed!\n"); -#else - /* unregister_chrdev returns void now */ - unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME); -#endif -out: - return -1; +error: + return retval; } If you're seeing chardev 61 anywhere, you're NOT running the current code. Pretty much positive on this one. -- Jarod Wilson ja...@wi... |
From: Paul B. <pa...@in...> - 2011-03-30 03:15:16
|
Tue, 29 Mar 2011 16:06:38 -0400 Jarod Wilson <ja...@wi...>: > On Mar 26, 2011, at 5:37 AM, Wgge wrote: > > > Jarod Wilson <jarod@...> writes: > > > >> Nope, that's the right place, and while you may have built and > >> installed bits from there, I'm positive that's not what you're > >> actually seeing load on your system. chardev 61 went away quite > >> a few months ago. We use a dynamic miscdev now, which typically > >> ends up being something in the high 240s or low 250s. Look in > >> your kernel tree, see if there isn't another lirc_dev.ko and > >> lirc_sir.ko. > > > > Same problem seen. If chardev 61 is gone, why we see configure scripts > default > > it to 61? > > --with-major=value specify the device major for the driver (61) > > This is also seen in gcc options when making: > > -DIRCTL_DEV_MAJOR=61 > > Unused legacy cruft. Its been unused in lirc git since October 20, > 2010, via commit 2f41e817, the most relevant excerpt of which is: > > static int __init lirc_dev_init(void) > { > - if (register_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME, &lirc_dev_fops)) > { > - printk(KERN_ERR "lirc_dev: register_chrdev failed\n"); > - goto out; > - } > + int retval; > > lirc_class = class_create(THIS_MODULE, "lirc"); > if (IS_ERR(lirc_class)) { > + retval = PTR_ERR(lirc_class); > printk(KERN_ERR "lirc_dev: class_create failed\n"); > - goto out_unregister; > + goto error; > + } > + > + retval = alloc_chrdev_region(&lirc_base_dev, 0, MAX_IRCTL_DEVICES, > + IRCTL_DEV_NAME); > + if (retval) { > + class_destroy(lirc_class); > + printk(KERN_ERR "lirc_dev: alloc_chrdev_region failed\n"); > + goto error; > } > > printk(KERN_INFO "lirc_dev: IR Remote Control driver registered, " > "major %d \n", IRCTL_DEV_MAJOR); Ok, looks like printk uses deprecated varliable IRCTL_DEV_MAJOR to tell us what number is registered. Here should be MAJOR(lirc_base_dev) instead of it. > > - return 0; > - > -out_unregister: > -#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 23) > - if (unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME)) > - printk(KERN_ERR "lirc_dev: unregister_chrdev failed!\n"); > -#else > - /* unregister_chrdev returns void now */ > - unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME); > -#endif > -out: > - return -1; > +error: > + return retval; > } |
From: Jarod W. <ja...@wi...> - 2011-03-30 17:41:25
|
On Mar 29, 2011, at 11:15 PM, Paul Bordukoff wrote: > Tue, 29 Mar 2011 16:06:38 -0400 Jarod Wilson <ja...@wi...>: > >> On Mar 26, 2011, at 5:37 AM, Wgge wrote: >> >>> Jarod Wilson <jarod@...> writes: >>> >>>> Nope, that's the right place, and while you may have built and >>>> installed bits from there, I'm positive that's not what you're >>>> actually seeing load on your system. chardev 61 went away quite >>>> a few months ago. We use a dynamic miscdev now, which typically >>>> ends up being something in the high 240s or low 250s. Look in >>>> your kernel tree, see if there isn't another lirc_dev.ko and >>>> lirc_sir.ko. >>> >>> Same problem seen. If chardev 61 is gone, why we see configure scripts >> default >>> it to 61? >>> --with-major=value specify the device major for the driver (61) >>> This is also seen in gcc options when making: >>> -DIRCTL_DEV_MAJOR=61 >> >> Unused legacy cruft. Its been unused in lirc git since October 20, >> 2010, via commit 2f41e817, the most relevant excerpt of which is: >> >> static int __init lirc_dev_init(void) >> { >> - if (register_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME, &lirc_dev_fops)) >> { >> - printk(KERN_ERR "lirc_dev: register_chrdev failed\n"); >> - goto out; >> - } >> + int retval; >> >> lirc_class = class_create(THIS_MODULE, "lirc"); >> if (IS_ERR(lirc_class)) { >> + retval = PTR_ERR(lirc_class); >> printk(KERN_ERR "lirc_dev: class_create failed\n"); >> - goto out_unregister; >> + goto error; >> + } >> + >> + retval = alloc_chrdev_region(&lirc_base_dev, 0, MAX_IRCTL_DEVICES, >> + IRCTL_DEV_NAME); >> + if (retval) { >> + class_destroy(lirc_class); >> + printk(KERN_ERR "lirc_dev: alloc_chrdev_region failed\n"); >> + goto error; >> } >> >> printk(KERN_INFO "lirc_dev: IR Remote Control driver registered, " >> "major %d \n", IRCTL_DEV_MAJOR); > > Ok, looks like printk uses deprecated varliable IRCTL_DEV_MAJOR to tell us what number is registered. Here should be MAJOR(lirc_base_dev) instead of it. Oh, crap, you're right. lirc-git still has the above, while the in-kernel bits have long since been changed to: printk(KERN_INFO "lirc_dev: IR Remote Control driver registered, " "major %d \n", MAJOR(lirc_base_dev)); Okay, my mistake on that one then. -- Jarod Wilson ja...@wi... |
From: Paul B. <pa...@in...> - 2011-03-31 02:49:24
|
Wed, 30 Mar 2011 13:41:26 -0400 Jarod Wilson <ja...@wi...>: > On Mar 29, 2011, at 11:15 PM, Paul Bordukoff wrote: > > > Tue, 29 Mar 2011 16:06:38 -0400 Jarod Wilson <ja...@wi...>: > > > >> On Mar 26, 2011, at 5:37 AM, Wgge wrote: > >> > >>> Jarod Wilson <jarod@...> writes: > >>> > >>>> Nope, that's the right place, and while you may have built and > >>>> installed bits from there, I'm positive that's not what you're > >>>> actually seeing load on your system. chardev 61 went away quite > >>>> a few months ago. We use a dynamic miscdev now, which typically > >>>> ends up being something in the high 240s or low 250s. Look in > >>>> your kernel tree, see if there isn't another lirc_dev.ko and > >>>> lirc_sir.ko. > >>> > >>> Same problem seen. If chardev 61 is gone, why we see configure scripts > >> default > >>> it to 61? > >>> --with-major=value specify the device major for the driver (61) > >>> This is also seen in gcc options when making: > >>> -DIRCTL_DEV_MAJOR=61 > >> > >> Unused legacy cruft. Its been unused in lirc git since October 20, > >> 2010, via commit 2f41e817, the most relevant excerpt of which is: > >> > >> static int __init lirc_dev_init(void) > >> { > >> - if (register_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME, > &lirc_dev_fops)) > >> { > >> - printk(KERN_ERR "lirc_dev: register_chrdev failed\n"); > >> - goto out; > >> - } > >> + int retval; > >> > >> lirc_class = class_create(THIS_MODULE, "lirc"); > >> if (IS_ERR(lirc_class)) { > >> + retval = PTR_ERR(lirc_class); > >> printk(KERN_ERR "lirc_dev: class_create failed\n"); > >> - goto out_unregister; > >> + goto error; > >> + } > >> + > >> + retval = alloc_chrdev_region(&lirc_base_dev, 0, MAX_IRCTL_DEVICES, > >> + IRCTL_DEV_NAME); > >> + if (retval) { > >> + class_destroy(lirc_class); > >> + printk(KERN_ERR "lirc_dev: alloc_chrdev_region failed\n"); > >> + goto error; > >> } > >> > >> printk(KERN_INFO "lirc_dev: IR Remote Control driver registered, " > >> "major %d \n", IRCTL_DEV_MAJOR); > > > > Ok, looks like printk uses deprecated varliable IRCTL_DEV_MAJOR to tell us > what number is registered. Here should be MAJOR(lirc_base_dev) instead of it. > > Oh, crap, you're right. lirc-git still has the above, while the in-kernel > bits have long since been changed to: > > printk(KERN_INFO "lirc_dev: IR Remote Control driver registered, " > "major %d \n", MAJOR(lirc_base_dev)); Anyway it is a cosmetic change which does not influence on the "resource busy" problem. I found that the problem is in obsolete (?) code lirc_sir.c. Functions lirc_open and lirc_close should be the same as in lirc_it87.c from kernel (2.6.38) tree. They are don't use the MOD_IN_USE variable, but device_open. The problem was gone after this: --- ./lirc/drivers/lirc_sir/lirc_sir.c 2011-03-31 08:33:52.743000005 +0600 +++ /tmp/lirc_sir.c 2011-03-31 08:25:07.000000000 +0600 @@ -199,6 +199,7 @@ static int debug; printk(KERN_DEBUG LIRC_DRIVER_NAME ": " \ fmt, ## args); \ } while (0) +static bool device_open; /* SECTION: Prototypes */ @@ -278,16 +279,20 @@ static void safe_udelay(unsigned long us static int lirc_open(struct inode *inode, struct file *file) { spin_lock(&dev_lock); - if (MOD_IN_USE) { + if (device_open) { spin_unlock(&dev_lock); return -EBUSY; } + device_open = true; spin_unlock(&dev_lock); return 0; } static int lirc_close(struct inode *inode, struct file *file) { + spin_lock(&dev_lock); + device_open = false; + spin_unlock(&dev_lock); return 0; } |
From: Jarod W. <ja...@wi...> - 2011-03-31 21:41:43
|
On Mar 30, 2011, at 10:49 PM, Paul Bordukoff wrote: > Wed, 30 Mar 2011 13:41:26 -0400 Jarod Wilson <ja...@wi...>: > >> On Mar 29, 2011, at 11:15 PM, Paul Bordukoff wrote: >> >>> Tue, 29 Mar 2011 16:06:38 -0400 Jarod Wilson <ja...@wi...>: >>> >>>> On Mar 26, 2011, at 5:37 AM, Wgge wrote: >>>> >>>>> Jarod Wilson <jarod@...> writes: >>>>> >>>>>> Nope, that's the right place, and while you may have built and >>>>>> installed bits from there, I'm positive that's not what you're >>>>>> actually seeing load on your system. chardev 61 went away quite >>>>>> a few months ago. We use a dynamic miscdev now, which typically >>>>>> ends up being something in the high 240s or low 250s. Look in >>>>>> your kernel tree, see if there isn't another lirc_dev.ko and >>>>>> lirc_sir.ko. >>>>> >>>>> Same problem seen. If chardev 61 is gone, why we see configure scripts >>>> default >>>>> it to 61? >>>>> --with-major=value specify the device major for the driver (61) >>>>> This is also seen in gcc options when making: >>>>> -DIRCTL_DEV_MAJOR=61 >>>> >>>> Unused legacy cruft. Its been unused in lirc git since October 20, >>>> 2010, via commit 2f41e817, the most relevant excerpt of which is: >>>> >>>> static int __init lirc_dev_init(void) >>>> { >>>> - if (register_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME, >> &lirc_dev_fops)) >>>> { >>>> - printk(KERN_ERR "lirc_dev: register_chrdev failed\n"); >>>> - goto out; >>>> - } >>>> + int retval; >>>> >>>> lirc_class = class_create(THIS_MODULE, "lirc"); >>>> if (IS_ERR(lirc_class)) { >>>> + retval = PTR_ERR(lirc_class); >>>> printk(KERN_ERR "lirc_dev: class_create failed\n"); >>>> - goto out_unregister; >>>> + goto error; >>>> + } >>>> + >>>> + retval = alloc_chrdev_region(&lirc_base_dev, 0, MAX_IRCTL_DEVICES, >>>> + IRCTL_DEV_NAME); >>>> + if (retval) { >>>> + class_destroy(lirc_class); >>>> + printk(KERN_ERR "lirc_dev: alloc_chrdev_region failed\n"); >>>> + goto error; >>>> } >>>> >>>> printk(KERN_INFO "lirc_dev: IR Remote Control driver registered, " >>>> "major %d \n", IRCTL_DEV_MAJOR); >>> >>> Ok, looks like printk uses deprecated varliable IRCTL_DEV_MAJOR to tell us >> what number is registered. Here should be MAJOR(lirc_base_dev) instead of it. >> >> Oh, crap, you're right. lirc-git still has the above, while the in-kernel >> bits have long since been changed to: >> >> printk(KERN_INFO "lirc_dev: IR Remote Control driver registered, " >> "major %d \n", MAJOR(lirc_base_dev)); > > Anyway it is a cosmetic change which does not influence on the "resource busy" problem. Sorry, yes, meant to say as much. > I found that the problem is in obsolete (?) code lirc_sir.c. Functions lirc_open and lirc_close should be the same as in lirc_it87.c from kernel (2.6.38) tree. Um. Why look at the lirc_it87.c code and not the lirc_sir.c code in the 2.6.38 kernel tree? :) But yes, lirc_sir.c hasn't been resync'd with what's in the upstream kernel tree. Mostly because lirc_sir.c is an atrocious mess and a bit of a hack to begin with... (And it doesn't work reliably at all with the only hardware I have that is driven by it). > They are don't use the MOD_IN_USE variable, but device_open. The problem was gone after this: > --- ./lirc/drivers/lirc_sir/lirc_sir.c 2011-03-31 08:33:52.743000005 +0600 > +++ /tmp/lirc_sir.c 2011-03-31 08:25:07.000000000 +0600 > @@ -199,6 +199,7 @@ static int debug; > printk(KERN_DEBUG LIRC_DRIVER_NAME ": " \ > fmt, ## args); \ > } while (0) > +static bool device_open; > > /* SECTION: Prototypes */ > > @@ -278,16 +279,20 @@ static void safe_udelay(unsigned long us > static int lirc_open(struct inode *inode, struct file *file) > { > spin_lock(&dev_lock); > - if (MOD_IN_USE) { > + if (device_open) { > spin_unlock(&dev_lock); > return -EBUSY; > } > + device_open = true; > spin_unlock(&dev_lock); > return 0; > } > > static int lirc_close(struct inode *inode, struct file *file) > { > + spin_lock(&dev_lock); > + device_open = false; > + spin_unlock(&dev_lock); > return 0; > } There's an even better fix implemented in the in-kernel lirc_sir.c, which I'll throw into lirc git. Simply rip out the open and close functions and use lirc_dev_fop_open and lirc_dev_fop_close. -- Jarod Wilson ja...@wi... |
From: Paul B. <pa...@in...> - 2011-04-01 16:24:11
|
Everything is fine now, thanks! |