Bug 506839

Description of problem:
/dev/lirc0 can't be opened

Version-Release number of selected component (if applicable):
kernel-2.6.30-6.fc12.i586

How reproducible:
always

Steps to Reproduce:
1. load lirc_sir.ko
2. try to open /dev/lirc0 (e.g. with irrecord -d /dev/lirc0 foo.out)
3.
  
Actual results:
$ sudo irrecord -d /dev/lirc0 foo.out

irrecord -  application for recording IR-codes for usage with lirc

Copyright (C) 1998,1999 Christoph Bartelmus(lirc)

irrecord: could not open /dev/lirc0
irrecord: default_init(): Device or resource busy
irrecord: could not init hardware (lircd running ? --> close it, check permissions)

Expected results:
/dev/lirc0 can be opened (and irrecord gets to do whatever it is it does)

Additional info:
0) problem seems to be [...]/lirc_sir.c:lirc_open():
static int lirc_open(struct inode *inode, struct file *file)
{
        spin_lock(&dev_lock);
        if (module_refcount(THIS_MODULE)) {
                spin_unlock(&dev_lock);
                return -EBUSY;
        }
        spin_unlock(&dev_lock);
        return 0;
}

1) As far as I know, by the time this is run there is already a reference to the lirc_sir module so lirc_open() will always return -EBUSY. Basically the chain of events when open()'ing /dev/lirc0 _seems_ to be:

fs/open.c:
    do_sys_open()
fs/namei.c:
   do_filp_open()
fs/open.c:
    nameidata_to_filp()
    __dentry_open():
    include/linux/fs.h:
        fops_get()
        include/linux/module.h:
            try_module_get()
            __module_ref_addr()
    // open(), which actually is:
drivers/input/lirc/lirc_sir.c:
    lirc_open()

If this is correct, by the time lirc_open() is run there will always be a reference to the lirc_sir module, as a result of fops_get(), so lirc_open() will always fail.

2) There should be a number of possible solutions. However, since lirc_open() lacks any comment, it is hard to say what the code is actually trying to accomplish (i.e. what problems it tried to avoid). Therefore, I have not tried to draft a patch.