0

The kernel documentation says about free_irq the following :

This function must not be called from interrupt context.

Does it include software interrupts? How can I free an IRQ in a software IRQ function?

Thanks for your help,

Oswin
  • 539
  • 1
  • 6
  • 20

1 Answers1

0

Yes, that rule includes softirq context. The fact that you think you need to call free_irq() from softirq context is an indication that your design is a bit out of the ordinary -- in normal cases, free_irq() is used when a device being shut down, which is almost always from process context.

However if you really need to do it, the thing to do would be to defer it to process context via schedule_work() or some similar workqueue function. Of course you can't wait in your softirq for that deferred work to complete, so you'll have to defer any other work that comes after freeing the IRQ also.

It might be possible to give a better answer if you gave a bit more information about why you're trying to call free_irq() from interrupt context.

Roland
  • 6,227
  • 23
  • 29
  • I made a workaround that could be dramaticaly improved with de 'schedule_work()' operation. As 'schedule_work()' is non blocking meaning to [this document](http://www.ibm.com/developerworks/linux/library/l-tasklets/index.html) my softirq wouldn't have to wait, wouldn't it? My only constraint is to be sure the free_irq has operated before the next open, I think this can be done with a 'flush_work' in the open function. – Oswin Oct 01 '12 at 08:51
  • Sure, schedule_work() is non-blocking -- I just meant if you need the IRQ freed, then you have to wait for it. As far as "de 'schedule_work()' operation", is cancel_scheduled_work() what you're after? – Roland Oct 01 '12 at 09:39
  • I don't use the default work queue, so the corresponding functions are queue_work() and flush_work() – Oswin Oct 02 '12 at 07:47