When we use irq_set_chained_handler the irq line will not be disabled or not, when we are servicing the associated handler, as in case of request_irq.
相关问题
- Kernel oops Oops: 80000005 on arm embedded system
- Linux kernel behaviour on heap overrun or stack ov
- Where is the standard kernel libraries to let kern
- What is the difference between /dev/mem, /dev/kmem
- Conditional compilation based on functionality in
相关文章
- Enable dynamic debug for multiple files at boot
- Difference in ABI between x86_64 Linux functions a
- Why are i2c_smbus function not available? (I2C – E
- Why are there no debug symbols in my vmlinux when
- ccflag option in Makefile
- A HR timers precision study case
- How can the linux bottom halfs execute in interrup
- Using wait_event_interruptible and wake_up_all tog
It doesn't matter how the interrupt was setup. When any interrupt occurred, all interrupts (for this CPU) will be disabled during the interrupt handler. For example, on ARM architecture first place in C code where interrupt handling is found is
asm_do_IRQ()
function (defined inarch/arm/kernel/irq.c
). It's being called from assembler code. For any interrupt (whether it was requested byrequest_irq()
or byirq_set_chained_handler()
) the sameasm_do_IRQ()
function is called, and interrupts are disabled automatically by ARM CPU. See this answer for details.Historical notes
Also, it worth to be mentioned that some time ago Linux kernel was providing two types of interrupts: "fast" and "slow" ones. Fast interrupts (when using
IRQF_DISABLED
orSA_INTERRUPT
flag) were running with disabled interrupts, and those handlers supposed to be very short and quick. Slow interrupts, on the other hand, were running with re-enabled interrupts, because handlers for slow interrupts may take much of time to be handled.On modern versions of Linux kernel all interrupts are considered as "fast" and are running with interrupts disabled. Interrupts with huge handlers must be implemented as threaded (or enable interrupts manually in ISR using
local_irq_enable_in_hardirq()
).That behavior was changed in Linux kernel v2.6.35 by this commit. You can find more details about this here.
Refer https://www.kernel.org/doc/Documentation/gpio/driver.txt