Exporting a few bits of irq infrastructure.

PATCH Jonathan Cameron 1 participant 2 messages Mar 19, 2011 – Mar 25, 2011

Subsystems (2)

IIO IRQ

lore

Share & tools

lore

Jonathan Cameron

author

2011-03-19 17:15 UTC #0 lore raw

Hi Thomas,

Just a quick enquiry. Is there a reason to not allow exporting the symbols handle_simple_irq and irq_to_desc? Or is it simply a case that there is not normally a reason for having irq chips registered via modules?

My implementation of what I think you were suggesting the other day for handling our IIO triggers registers a separate irq chip for each trigger (currently with a compile time number of irq's per trigger). These are allocated from a pool set up in a boards platform init code. The device drivers can then query to get the next available irq for a given trigger and request that. Some trigggers are entirely instantiated based on
a request form userspace (or should be anyway - see Arnd's observations on iio-trig-sysfs). This could be done with a layer of indirection, but that would be annoyingly fiddly!

Anyhow, right now the patch is dependent on (cut out of a larger patch)

iff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index baa5c4a..eb3d53b 100644

kernel/irq/chip.c +1 -0

@@ -487,6 +487,7 @@ handle_simple_irq(unsigned int irq, struct irq_desc *desc)
 out_unlock:
 	raw_spin_unlock(&desc->lock);
 }
+EXPORT_SYMBOL_GPL(handle_simple_irq);
 
 /**
  *	handle_level_irq - Level type irq handler

kernel/irq/irqdesc.c +1 -0

index 282f202..d3765e2 100644
@@ -109,6 +109,7 @@ struct irq_desc *irq_to_desc(unsigned int irq)
 {
 	return radix_tree_lookup(&irq_desc_tree, irq);
 }
+EXPORT_SYMBOL(irq_to_desc);
 
 static void delete_irq_desc(unsigned int irq)
 {

Signature · 10 lines

1.7.3.4


We also need set_irq_flags in arch/arm/kernel/irq.c I think, but for
that I clearly need to also ask the arm guys so lets sort the two above
first.

Thanks,

Jonathan

Jonathan Cameron

author

2011-03-25 11:57 UTC #1 lore raw

Quoted 1 line · Jonathan Cameron

Hi Thomas,

Hi again, just wondering if you have a moment to comment on these exports? If not I'll post them to LKML and see if someone shouts!

Thanks,

Jonathan

Quoted 43 lines

Just a quick enquiry. Is there a reason to not allow exporting the symbols handle_simple_irq and irq_to_desc? Or is it simply a case that there is not normally a reason for having irq chips registered via modules?
My implementation of what I think you were suggesting the other day for handling our IIO triggers registers a separate irq chip for each trigger (currently with a compile time number of irq's per trigger). These are allocated from a pool set up in a boards platform init code. The device drivers can then query to get the next available irq for a given trigger and request that. Some trigggers are entirely instantiated based on
a request form userspace (or should be anyway - see Arnd's observations on iio-trig-sysfs). This could be done with a layer of indirection, but that would be annoyingly fiddly!
Anyhow, right now the patch is dependent on (cut out of a larger patch)
iff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index baa5c4a..eb3d53b 100644
kernel/irq/chip.c +1 -0
@@ -487,6 +487,7 @@ handle_simple_irq(unsigned int irq, struct irq_desc *desc)
 out_unlock:
 	raw_spin_unlock(&desc->lock);
 }
+EXPORT_SYMBOL_GPL(handle_simple_irq);
 
 /**
  *	handle_level_irq - Level type irq handler
kernel/irq/irqdesc.c +1 -0
index 282f202..d3765e2 100644
@@ -109,6 +109,7 @@ struct irq_desc *irq_to_desc(unsigned int irq)
 {
 	return radix_tree_lookup(&irq_desc_tree, irq);
 }
+EXPORT_SYMBOL(irq_to_desc);
 
 static void delete_irq_desc(unsigned int irq)
 {