Re: dummy irq trace 'Flags mismatch'

2013-04-30 Thread Jonathan Corbet 
On Tue, 30 Apr 2013 06:59:22 +0200 (CEST)
Jiri Kosina  wrote:

> Or have it depend on CONFIG_EXPERT would probably make most sense ... ?

We could also just have it tell you when you screwed up?  Something like
the following (compile tested only)?

jon
---
dummy-irq: require the user to specify an IRQ number

Reported-by: Dave Jones 
Signed-off-by: Jonathan Corbet 

diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
index 7014167..c37eeed 100644
--- a/drivers/misc/dummy-irq.c
+++ b/drivers/misc/dummy-irq.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 
-static int irq;
+static int irq = -1;
 
 static irqreturn_t dummy_interrupt(int irq, void *dev_id)
 {
@@ -36,6 +36,10 @@ static irqreturn_t dummy_interrupt(int irq, void *dev_id)
 
 static int __init dummy_irq_init(void)
 {
+   if (irq < 0) {
+   printk(KERN_ERR "dummy-irq: no IRQ given.  Use irq=N\n");
+   return -EIO;
+   }
if (request_irq(irq, _interrupt, IRQF_SHARED, "dummy_irq", )) 
{
printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
return -EIO;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dummy irq trace 'Flags mismatch'

2013-04-30 Thread Jonathan Corbet 
On Tue, 30 Apr 2013 06:59:22 +0200 (CEST)
Jiri Kosina jkos...@suse.cz wrote:

 Or have it depend on CONFIG_EXPERT would probably make most sense ... ?

We could also just have it tell you when you screwed up?  Something like
the following (compile tested only)?

jon
---
dummy-irq: require the user to specify an IRQ number

Reported-by: Dave Jones da...@redhat.com
Signed-off-by: Jonathan Corbet cor...@lwn.net

diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
index 7014167..c37eeed 100644
--- a/drivers/misc/dummy-irq.c
+++ b/drivers/misc/dummy-irq.c
@@ -19,7 +19,7 @@
 #include linux/irq.h
 #include linux/interrupt.h
 
-static int irq;
+static int irq = -1;
 
 static irqreturn_t dummy_interrupt(int irq, void *dev_id)
 {
@@ -36,6 +36,10 @@ static irqreturn_t dummy_interrupt(int irq, void *dev_id)
 
 static int __init dummy_irq_init(void)
 {
+   if (irq  0) {
+   printk(KERN_ERR dummy-irq: no IRQ given.  Use irq=N\n);
+   return -EIO;
+   }
if (request_irq(irq, dummy_interrupt, IRQF_SHARED, dummy_irq, irq)) 
{
printk(KERN_ERR dummy-irq: cannot register IRQ %d\n, irq);
return -EIO;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dummy irq trace 'Flags mismatch'

2013-04-29 Thread Jiri Kosina 
On Mon, 29 Apr 2013, Dave Jones wrote:

> When set to built-in, the dummy irq driver causes this trace when I boot..
> 
> [3.996055] genirq: Flags mismatch irq 0. 0080 (dummy_irq) vs. 
> 00015a20 (timer)
> [3.997055] Pid: 1, comm: swapper/0 Not tainted 3.9.0+ #29
> [3.997768] Call Trace:
> [3.998127]  [] __setup_irq+0x515/0x550
> [3.998827]  [] ? loop_init+0x150/0x150
> [3.999530]  [] ? transfer_xor+0x160/0x160
> [4.000259]  [] request_threaded_irq+0xf9/0x1a0
> [4.001041]  [] ? loop_init+0x150/0x150
> [4.001740]  [] dummy_irq_init+0x2c/0x60
> [4.002450]  [] do_one_initcall+0x122/0x170
> [4.003191]  [] kernel_init_freeable+0x15b/0x1db
> [4.003978]  [] ? do_early_param+0x88/0x88
> [4.004710]  [] ? rest_init+0x140/0x140
> [4.005413]  [] kernel_init+0xe/0x180
> [4.006094]  [] ret_from_fork+0x7c/0xb0
> [4.006789]  [] ? rest_init+0x140/0x140
> [4.007561] dummy-irq: cannot register IRQ 0

Thanks for the report, Dave. That's actually kind of expected -- when one 
of the handlers on the IRQ line that is being debugged doesn't share IRQs, 
this is exactly what you want to get by the dummy-irq debugging facility.

In this case you haven't specified any IRQ# to the dummy-irq driver via 
kernel commandline, i.e. IRQ# is 0, and timer is not sharing IRQs, 
therefore dummy-irq debugging facility did its job, and you know that the 
IRQ can't be shared.

Not really sure whether this is something to fix. We could make dummy-irq 
a module-only thing, but that might be counter-productive in cases you 
really want to debug very early problems.

Or have it depend on CONFIG_EXPERT would probably make most sense ... ?

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dummy irq trace 'Flags mismatch'

2013-04-29 Thread Jiri Kosina 
On Mon, 29 Apr 2013, Dave Jones wrote:

 When set to built-in, the dummy irq driver causes this trace when I boot..
 
 [3.996055] genirq: Flags mismatch irq 0. 0080 (dummy_irq) vs. 
 00015a20 (timer)
 [3.997055] Pid: 1, comm: swapper/0 Not tainted 3.9.0+ #29
 [3.997768] Call Trace:
 [3.998127]  [810f8635] __setup_irq+0x515/0x550
 [3.998827]  [81f00e8c] ? loop_init+0x150/0x150
 [3.999530]  [8146adf0] ? transfer_xor+0x160/0x160
 [4.000259]  [810f8809] request_threaded_irq+0xf9/0x1a0
 [4.001041]  [81f00e8c] ? loop_init+0x150/0x150
 [4.001740]  [81f00eb8] dummy_irq_init+0x2c/0x60
 [4.002450]  [810002e2] do_one_initcall+0x122/0x170
 [4.003191]  [81ecef5c] kernel_init_freeable+0x15b/0x1db
 [4.003978]  [81ece7da] ? do_early_param+0x88/0x88
 [4.004710]  [816a87e0] ? rest_init+0x140/0x140
 [4.005413]  [816a87ee] kernel_init+0xe/0x180
 [4.006094]  [816ce91c] ret_from_fork+0x7c/0xb0
 [4.006789]  [816a87e0] ? rest_init+0x140/0x140
 [4.007561] dummy-irq: cannot register IRQ 0

Thanks for the report, Dave. That's actually kind of expected -- when one 
of the handlers on the IRQ line that is being debugged doesn't share IRQs, 
this is exactly what you want to get by the dummy-irq debugging facility.

In this case you haven't specified any IRQ# to the dummy-irq driver via 
kernel commandline, i.e. IRQ# is 0, and timer is not sharing IRQs, 
therefore dummy-irq debugging facility did its job, and you know that the 
IRQ can't be shared.

Not really sure whether this is something to fix. We could make dummy-irq 
a module-only thing, but that might be counter-productive in cases you 
really want to debug very early problems.

Or have it depend on CONFIG_EXPERT would probably make most sense ... ?

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/