From: Maxim L. <max...@gm...> - 2009-08-24 13:29:47
|
I have just tested my driver against the ubuntu stock kernel 2.6.28-11-generic It works just fine. Christoph, small question, you put my driver in #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29) Is there a reason, or this is a precaution? If no objections, I lower this to 2.6.28 NOTE to anyone who needs to install this in ubuntu: If you want to get this driver working in ubuntu, you need first to remove ubuntu lirc kernel modules, if installed. Otherwise, lirc_dev from ubuntu will be used, and will conflict with new installed one. Also, if you want to use uinput, you need to load it manually. sudo modprobe uinput Best regards, Maxim Levitsky |
From: Jarod W. <ja...@wi...> - 2009-08-24 15:16:26
|
On Aug 24, 2009, at 9:29 AM, Maxim Levitsky wrote: > I have just tested my driver against the ubuntu stock kernel > 2.6.28-11-generic > > It works just fine. > > Christoph, small question, you put my driver in > #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29) > > Is there a reason, or this is a precaution? > > If no objections, I lower this to 2.6.28 99% certain its just a precautionary measure, go ahead and lower it. > NOTE to anyone who needs to install this in ubuntu: > > If you want to get this driver working in ubuntu, you need first to > remove ubuntu lirc kernel modules, if installed. > Otherwise, lirc_dev from ubuntu will be used, and will conflict with > new > installed one. You don't *need* to remove them. You simply need to install the lirc_dev and lirc_ene0100 modules built from cvs into a module path with higher precedence and run depmod to update module dependency info, and the newer one will get used. Of course, if you subsequently try loading one of the other modules, it may well puke on itself, due to an lirc_dev mismatch, so maybe removing the ubuntu-provided bits isn't such a bad idea after all... -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2009-08-24 15:53:05
|
On Mon, 2009-08-24 at 11:14 -0400, Jarod Wilson wrote: > On Aug 24, 2009, at 9:29 AM, Maxim Levitsky wrote: > > > I have just tested my driver against the ubuntu stock kernel > > 2.6.28-11-generic > > > > It works just fine. > > > > Christoph, small question, you put my driver in > > #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29) > > > > Is there a reason, or this is a precaution? > > > > If no objections, I lower this to 2.6.28 > > 99% certain its just a precautionary measure, go ahead and lower it. > > > NOTE to anyone who needs to install this in ubuntu: > > > > If you want to get this driver working in ubuntu, you need first to > > remove ubuntu lirc kernel modules, if installed. > > Otherwise, lirc_dev from ubuntu will be used, and will conflict with > > new > > installed one. > > You don't *need* to remove them. You simply need to install the > lirc_dev and lirc_ene0100 modules built from cvs into a module path > with higher precedence and run depmod to update module dependency > info, and the newer one will get used. Of course, if you subsequently > try loading one of the other modules, it may well puke on itself, due > to an lirc_dev mismatch, so maybe removing the ubuntu-provided bits > isn't such a bad idea after all... Indeed. lirc installs the drivers to /lib/.../misc, and I guess that has lower precedence that kernel/ubuntu. I'll soon test this driver on older kernels as well, as I suspect that it will work there as well. (If not, porting probably is trivial) Best regards, Maxim Levitsky |
From: Jarod W. <ja...@wi...> - 2009-08-24 15:58:47
|
On Aug 24, 2009, at 11:52 AM, Maxim Levitsky wrote: >> >>> NOTE to anyone who needs to install this in ubuntu: >>> >>> If you want to get this driver working in ubuntu, you need first to >>> remove ubuntu lirc kernel modules, if installed. >>> Otherwise, lirc_dev from ubuntu will be used, and will conflict with >>> new >>> installed one. >> >> You don't *need* to remove them. You simply need to install the >> lirc_dev and lirc_ene0100 modules built from cvs into a module path >> with higher precedence and run depmod to update module dependency >> info, and the newer one will get used. Of course, if you subsequently >> try loading one of the other modules, it may well puke on itself, due >> to an lirc_dev mismatch, so maybe removing the ubuntu-provided bits >> isn't such a bad idea after all... > > Indeed. > lirc installs the drivers to /lib/.../misc, and I guess that has lower > precedence that kernel/ubuntu. That's... Fail. Actually, that might be standard modprobe precedence, not sure. I typically build from git and install by hand, into / lib/.../extra/ myself, which does have a higher precedence that kernel/ drivers/input/lirc/, which is where the kernel-provided drivers land in my distro of choice. > I'll soon test this driver on older kernels as well, as I suspect that > it will work there as well. > (If not, porting probably is trivial) If you're up for it, by all means, have at it. -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2009-08-25 13:02:16
|
On Mon, 2009-08-24 at 11:56 -0400, Jarod Wilson wrote: > On Aug 24, 2009, at 11:52 AM, Maxim Levitsky wrote: > >> > >>> NOTE to anyone who needs to install this in ubuntu: > >>> > >>> If you want to get this driver working in ubuntu, you need first to > >>> remove ubuntu lirc kernel modules, if installed. > >>> Otherwise, lirc_dev from ubuntu will be used, and will conflict with > >>> new > >>> installed one. > >> > >> You don't *need* to remove them. You simply need to install the > >> lirc_dev and lirc_ene0100 modules built from cvs into a module path > >> with higher precedence and run depmod to update module dependency > >> info, and the newer one will get used. Of course, if you subsequently > >> try loading one of the other modules, it may well puke on itself, due > >> to an lirc_dev mismatch, so maybe removing the ubuntu-provided bits > >> isn't such a bad idea after all... > > > > Indeed. > > lirc installs the drivers to /lib/.../misc, and I guess that has lower > > precedence that kernel/ubuntu. > > That's... Fail. Actually, that might be standard modprobe precedence, > not sure. I typically build from git and install by hand, into / > lib/.../extra/ myself, which does have a higher precedence that kernel/ > drivers/input/lirc/, which is where the kernel-provided drivers land > in my distro of choice. > > > I'll soon test this driver on older kernels as well, as I suspect that > > it will work there as well. > > (If not, porting probably is trivial) > > If you're up for it, by all means, have at it. > Ok, I have updated the driver. Now it compiles on kernels from 2.6.16 On 2.6.15 it give me 'outb' undefined, which is probably trivial to fix, but I think this kernel is too old to bother. I didn't 'run test' this driver on kernels below 2.6.28, because due to few stupid problems they don't boot here. one is that I have switched the system to ext4..., and another I have installed very new udev, and it doesn't like to run on 2.6.26 But I almost fully sure, driver will work fine there too. Jarod Wilson, by now the patches I have prepared against your git tree are quite outdated. Should I send an update, or you pull updates automatically from cvs tree? Best regards, Maxim Levitsky |
From: Jarod W. <ja...@wi...> - 2009-08-25 13:15:01
|
On Aug 25, 2009, at 9:01 AM, Maxim Levitsky wrote: >> ... >>> I'll soon test this driver on older kernels as well, as I suspect >>> that >>> it will work there as well. >>> (If not, porting probably is trivial) >> >> If you're up for it, by all means, have at it. >> > > Ok, I have updated the driver. > Now it compiles on kernels from 2.6.16 > On 2.6.15 it give me 'outb' undefined, which is probably trivial to > fix, > but I think this kernel is too old to bother. > > I didn't 'run test' this driver on kernels below 2.6.28, because due > to > few stupid problems they don't boot here. > one is that I have switched the system to ext4..., and another I have > installed very new udev, and it doesn't like to run on 2.6.26 > But I almost fully sure, driver will work fine there too. > > Jarod Wilson, by now the patches I have prepared against your git tree > are quite outdated. Should I send an update, or you pull updates > automatically from cvs tree? Yeah, I've been pulling bits across from cvs. Doing so manually at the moment, though it'd be good to finally get around to automatically exporting from cvs into git. That's on the TODO list, just haven't had the time to do it... -- Jarod Wilson ja...@wi... |
From: Jeremy Y. <jy...@um...> - 2009-08-27 15:23:08
|
I've been waiting for the code to stabilize a bit, but I've already updated my Ubuntu package to recognize the new driver. If it's pretty stable now I'll roll up a new package and upload it to my PPA. My changes have been integrated into the main Ubuntu LIRC package, so as of 9.10 we should have LIRC 0.8.6-CVS available on Ubuntu. If we can get a full 0.8.6 release before that, I'm sure it would make the Ubuntu folks happy :) Still no progress on lirc-properties... I got swamped. Jeremy Jarod Wilson wrote the following on 8/25/2009 9:12 AM: > On Aug 25, 2009, at 9:01 AM, Maxim Levitsky wrote: > >>> ... >>> >>>> I'll soon test this driver on older kernels as well, as I suspect >>>> that >>>> it will work there as well. >>>> (If not, porting probably is trivial) >>>> >>> If you're up for it, by all means, have at it. >>> >>> >> Ok, I have updated the driver. >> Now it compiles on kernels from 2.6.16 >> On 2.6.15 it give me 'outb' undefined, which is probably trivial to >> fix, >> but I think this kernel is too old to bother. >> >> I didn't 'run test' this driver on kernels below 2.6.28, because due >> to >> few stupid problems they don't boot here. >> one is that I have switched the system to ext4..., and another I have >> installed very new udev, and it doesn't like to run on 2.6.26 >> But I almost fully sure, driver will work fine there too. >> >> Jarod Wilson, by now the patches I have prepared against your git tree >> are quite outdated. Should I send an update, or you pull updates >> automatically from cvs tree? >> > > Yeah, I've been pulling bits across from cvs. Doing so manually at the > moment, though it'd be good to finally get around to automatically > exporting from cvs into git. That's on the TODO list, just haven't had > the time to do it... > > |
From: Maxim L. <max...@gm...> - 2009-08-27 15:26:08
|
Here I prepared a update of my driver in your tree. I have also accidentally compiled it in the kernel binary, and found out that driver doesn't work. It appears that lirc_dev checks in few places that module owner isn't NULL, but it can be NULL is driver is compiled in. I have removed all these checks, and now my drivers works fine, while both lirc_dev and lirc_ene0100 are compiled in. Best regards, Maxim Levitsky |
From: Maxim L. <max...@gm...> - 2009-08-27 15:28:19
|
>From 5984b2f11c4c3c2ccae66cd992b9ad0f45d44f24 Mon Sep 17 00:00:00 2001 From: Maxim Levitsky <max...@gm...> Date: Thu, 27 Aug 2009 18:20:57 +0300 Subject: [PATCH] Few minor updates for ene0100 driver: * Make pnp code more portable. * Clean up the printk code * Add a message that states that transmission support isn't yet done * remove few hunks accidentally introduced from CVS Signed-off-by: Maxim Levitsky <max...@gm...> --- drivers/input/lirc/lirc_ene0100.c | 94 ++++++++++++++++--------------------- drivers/input/lirc/lirc_ene0100.h | 8 ++- 2 files changed, 45 insertions(+), 57 deletions(-) diff --git a/drivers/input/lirc/lirc_ene0100.c b/drivers/input/lirc/lirc_ene0100.c index c95f95a..e84368f 100644 --- a/drivers/input/lirc/lirc_ene0100.c +++ b/drivers/input/lirc/lirc_ene0100.c @@ -127,44 +127,39 @@ static int ene_hw_detect(struct ene_device *dev) old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD); if (hw_revision == 0xFF) { - printk(KERN_WARNING ENE_DRIVER_NAME ": " - "device seems to be disabled\n"); - printk(KERN_WARNING ENE_DRIVER_NAME ": " + ene_printk(KERN_WARNING, "device seems to be disabled\n"); + ene_printk(KERN_WARNING, "send a mail to lir...@li...\n"); - - printk(KERN_WARNING ENE_DRIVER_NAME ": " - "please attach output of acpidump\n"); + ene_printk(KERN_WARNING, "please attach output of acpidump\n"); return -ENODEV; } if (chip_major == 0x33) { - printk(KERN_NOTICE ENE_DRIVER_NAME ": " - "chips 0x33xx aren't supported yet\n"); + ene_printk(KERN_WARNING, "chips 0x33xx aren't supported yet\n"); return -ENODEV; } if (chip_major == 0x39 && chip_minor == 0x26 && hw_revision == 0xC0) { dev->hw_revision = ENE_HW_C; - printk(KERN_WARNING ENE_DRIVER_NAME ": " + ene_printk(KERN_WARNING, "KB3926C detected, driver support is not complete!\n"); } else if (old_ver == 0x24 && hw_revision == 0xC0) { dev->hw_revision = ENE_HW_B; - - printk(KERN_NOTICE ENE_DRIVER_NAME ": " - "KB3926B detected\n"); + ene_printk(KERN_NOTICE, "KB3926B detected\n"); } else { dev->hw_revision = ENE_HW_D; + ene_printk(KERN_WARNING, + "unknown ENE chip detected, assuming KB3926D\n"); + ene_printk(KERN_WARNING, "driver support incomplete"); - printk(KERN_WARNING ENE_DRIVER_NAME ": " - "unknown ENE chip detected, assuming KB3926D\n"); } - printk(KERN_NOTICE ENE_DRIVER_NAME ": " - "chip is 0x%02x%02x - 0x%02x, 0x%02x\n", - chip_major, chip_minor, old_ver, hw_revision); + ene_printk(KERN_DEBUG, "chip is 0x%02x%02x - 0x%02x, 0x%02x\n", + chip_major, chip_minor, old_ver, hw_revision); + /* detect features hardware supports */ @@ -179,12 +174,24 @@ static int ene_hw_detect(struct ene_device *dev) dev->hw_fan_as_normal_input = dev->hw_learning_and_tx_capable && fw_capabilities & ENE_FW2_FAN_AS_NRML_IN; - printk(KERN_NOTICE ENE_DRIVER_NAME ": hardware features:\n"); - printk(KERN_NOTICE ENE_DRIVER_NAME - ": learning and tx %s, gpio40_learn %s, fan_in %s\n", + ene_printk(KERN_NOTICE, "hardware features:\n"); + ene_printk(KERN_NOTICE, + "learning and tx %s, gpio40_learn %s, fan_in %s\n", dev->hw_learning_and_tx_capable ? "on" : "off", dev->hw_gpio40_learning ? "on" : "off", dev->hw_fan_as_normal_input ? "on" : "off"); + + if (!dev->hw_learning_and_tx_capable && enable_learning) + enable_learning = 0; + + if (dev->hw_learning_and_tx_capable) { + ene_printk(KERN_WARNING, + "Device supports transmitting, but the driver doesn't\n"); + ene_printk(KERN_WARNING, + "due to lack of hardware to test against.\n"); + ene_printk(KERN_WARNING, + "Send a mail to: lir...@li...\n"); + } return 0; } @@ -208,13 +215,6 @@ static int ene_hw_init(void *data) } ene_hw_write_reg(dev, ENE_CIR_CONF2, 0x00); - - if (!dev->hw_learning_and_tx_capable && enable_learning) { - printk(KERN_ERR ENE_DRIVER_NAME ": " - "Device doesn't support wide band (learning) reciever\n"); - enable_learning = 0; - } - ene_set_inputs(dev, enable_learning); /* set sampling period */ @@ -258,7 +258,6 @@ static void ene_enable_fan_recieve(struct ene_device *dev, int enable) ene_hw_write_reg(dev, ENE_FAN_AS_IN1, ENE_FAN_AS_IN1_EN); ene_hw_write_reg(dev, ENE_FAN_AS_IN2, ENE_FAN_AS_IN2_EN); } - dev->fan_input_inuse = enable; } @@ -381,11 +380,7 @@ static void ene_set_idle(struct ene_device *dev, int idle) } /* interrupt handler */ -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 19) static irqreturn_t ene_hw_irq(int irq, void *data) -#else -static irqreturn_t ene_hw_irq(int irq, void *data, struct pt_regs *regs) -#endif { u16 hw_value; int i, hw_sample; @@ -469,7 +464,6 @@ static irqreturn_t ene_hw_irq(int irq, void *data, struct pt_regs *regs) static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *dev_id) { - struct resource *res; struct ene_device *dev; struct lirc_driver *lirc_driver; int error = -ENOMEM; @@ -482,22 +476,6 @@ static int ene_probe(struct pnp_dev *pnp_dev, dev->pnp_dev = pnp_dev; pnp_set_drvdata(pnp_dev, dev); - /* validate and read resources */ - error = -ENODEV; - res = pnp_get_resource(pnp_dev, IORESOURCE_IO, 0); - if (!pnp_resource_valid(res)) - goto err2; - - dev->hw_io = res->start; - - if (pnp_resource_len(res) < ENE_MAX_IO) - goto err2; - - res = pnp_get_resource(pnp_dev, IORESOURCE_IRQ, 0); - if (!pnp_resource_valid(res)) - goto err2; - - dev->irq = res->start; /* prepare lirc interface */ error = -ENOMEM; @@ -530,6 +508,16 @@ static int ene_probe(struct pnp_dev *pnp_dev, if (lirc_register_driver(lirc_driver)) goto err5; + /* validate resources */ + if (!pnp_port_valid(pnp_dev, 0) || pnp_port_len(pnp_dev, 0) < ENE_MAX_IO) + goto err6; + + if (!pnp_irq_valid(pnp_dev, 0)) + goto err6; + + dev->hw_io = pnp_port_start(pnp_dev, 0); + dev->irq = pnp_irq(pnp_dev, 0); + /* claim the resources */ error = -EBUSY; if (!request_region(dev->hw_io, ENE_MAX_IO, ENE_DRIVER_NAME)) @@ -544,8 +532,7 @@ static int ene_probe(struct pnp_dev *pnp_dev, if (error) goto err8; - printk(KERN_NOTICE ENE_DRIVER_NAME ": " - "driver has been succesfully loaded\n"); + ene_printk(KERN_NOTICE, "driver has been succesfully loaded\n"); return 0; err8: @@ -624,8 +611,8 @@ static struct pnp_driver ene_driver = { static int __init ene_init(void) { if (sample_period < 5) { - printk(KERN_ERR ENE_DRIVER_NAME ": sample period must be at " - "least 5 us, (at least 30 recommended)\n"); + ene_printk(KERN_ERR, "sample period must be at\n"); + ene_printk(KERN_ERR, "least 5 us, (at least 30 recommended)\n"); return -EINVAL; } return pnp_register_driver(&ene_driver); @@ -655,4 +642,3 @@ MODULE_LICENSE("GPL"); module_init(ene_init); module_exit(ene_exit); -#endif diff --git a/drivers/input/lirc/lirc_ene0100.h b/drivers/input/lirc/lirc_ene0100.h index 7841c19..01cffa2 100644 --- a/drivers/input/lirc/lirc_ene0100.h +++ b/drivers/input/lirc/lirc_ene0100.h @@ -19,9 +19,8 @@ * USA */ -#include "drivers/kcompat.h" -#include "drivers/lirc.h" -#include "drivers/lirc_dev/lirc_dev.h" +#include "lirc.h" +#include "lirc_dev.h" /* hardware address */ #define ENE_STATUS 0 /* hardware status - unused */ @@ -143,6 +142,9 @@ #define ENE_HW_C 2 /* 3926C */ #define ENE_HW_D 3 /* 3926D */ +#define ene_printk(level, text, ...) \ + printk(level ENE_DRIVER_NAME ": " text, ## __VA_ARGS__) + struct ene_device { struct pnp_dev *pnp_dev; struct lirc_driver *lirc_driver; -- 1.6.0.4 |
From: Maxim L. <max...@gm...> - 2009-08-27 15:30:06
|
>From 8dbfe6f7991880a1b7b7ed547625018a84456ef3 Mon Sep 17 00:00:00 2001 From: Maxim Levitsky <max...@gm...> Date: Thu, 27 Aug 2009 18:20:58 +0300 Subject: [PATCH] Fix lirc_dev when the driver is compiled in Don't check that module owner is NULL, as it will be when module is compiled in kernel functions that deal with module owner deal correctly with NULL pointers (like module_get, module_put) Signed-off-by: Maxim Levitsky <max...@gm...> --- drivers/input/lirc/lirc_dev.c | 15 +-------------- 1 files changed, 1 insertions(+), 14 deletions(-) diff --git a/drivers/input/lirc/lirc_dev.c b/drivers/input/lirc/lirc_dev.c index fa0d169..a23bfea 100644 --- a/drivers/input/lirc/lirc_dev.c +++ b/drivers/input/lirc/lirc_dev.c @@ -260,13 +260,6 @@ int lirc_register_driver(struct lirc_driver *d) } } - if (d->owner == NULL) { - printk(KERN_ERR "lirc_dev: lirc_register_driver: " - "no module owner registered\n"); - err = -EBADRQC; - goto out; - } - mutex_lock(&lirc_dev_lock); minor = d->minor; @@ -456,7 +449,7 @@ int lirc_dev_fop_open(struct inode *inode, struct file *file) goto error; } - if (ir->d.owner != NULL && try_module_get(ir->d.owner)) { + if (try_module_get(ir->d.owner)) { ++ir->open; retval = ir->d.set_use_inc(ir->d.data); @@ -468,12 +461,6 @@ int lirc_dev_fop_open(struct inode *inode, struct file *file) } if (ir->task) wake_up_process(ir->task); - } else { - if (ir->d.owner == NULL) - dprintk(LOGHEAD "no module owner!!!\n", - ir->d.name, ir->d.minor); - - retval = -ENODEV; } error: -- 1.6.0.4 |
From: Jarod W. <ja...@wi...> - 2009-08-28 21:19:07
|
On Aug 27, 2009, at 11:25 AM, Maxim Levitsky wrote: > Here I prepared a update of my driver in your tree. > I have also accidentally compiled it in the kernel binary, and found > out > that driver doesn't work. > > It appears that lirc_dev checks in few places that module owner isn't > NULL, but it can be NULL is driver is compiled in. > > I have removed all these checks, and now my drivers works fine, while > both lirc_dev and lirc_ene0100 are compiled in. Committed and pushed, thanks much. -- Jarod Wilson ja...@wi... |
From: Jeremy Y. <jy...@um...> - 2009-08-28 21:43:45
|
Ubuntu PPA updated: https://launchpad.net/~jyoder/+archive/ppa <https://launchpad.net/%7Ejyoder/+archive/ppa> This is against CVS as of 4:35pm EST today and should work fine with the lirc_ene0100 module. Please check! NOTE: You have to install "lirc-modules-source" AND "lirc" to get the updated drivers. Either reboot after or run "sudo /etc/init.d/lirc restart" Jeremy Jarod Wilson wrote the following on 8/28/2009 5:16 PM: > On Aug 27, 2009, at 11:25 AM, Maxim Levitsky wrote: > > >> Here I prepared a update of my driver in your tree. >> I have also accidentally compiled it in the kernel binary, and found >> out >> that driver doesn't work. >> >> It appears that lirc_dev checks in few places that module owner isn't >> NULL, but it can be NULL is driver is compiled in. >> >> I have removed all these checks, and now my drivers works fine, while >> both lirc_dev and lirc_ene0100 are compiled in. >> > > Committed and pushed, thanks much. > > |