Bug 506839 - lirc_sir: /dev/lirc0 can't be opened
lirc_sir: /dev/lirc0 can't be opened
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-18 16:36 EDT by Paul Bolle
Modified: 2009-08-30 00:58 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-30 00:58:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Bolle 2009-06-18 16:36:38 EDT
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@bartelmus.de)

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.
Comment 1 Jarod Wilson 2009-07-09 23:57:02 EDT
Finally looked at this some this week. Yeah, that check in lirc_open is bogus. Its a side-effect of the conversion to proper fops and whatnot that we're working on. I believe the next rawhide kernel should work better -- I've more or less got an actisys lirc_sir-driven dongle working with it now. Basically, we just drop lirc_sir's lirc_open() and lirc_close() and use the default open and close fops from lirc_dev now.
Comment 2 Jarod Wilson 2009-08-30 00:58:08 EDT
The device can be opened in recent kernels, and my own lirc_sir device at least mostly works (actisys dongle), so closing this bug.

Note You need to log in before you can comment on or make changes to this bug.