{"id":4175,"date":"2022-12-20T17:39:37","date_gmt":"2022-12-20T20:39:37","guid":{"rendered":"http:\/\/lode.uno\/linux-man\/index.php\/2022\/12\/20\/request_irq-man9\/"},"modified":"2022-12-20T17:39:37","modified_gmt":"2022-12-20T20:39:37","slug":"request_irq-man9","status":"publish","type":"post","link":"https:\/\/lode.uno\/linux-man\/2022\/12\/20\/request_irq-man9\/","title":{"rendered":"REQUEST_IRQ (man9)"},"content":{"rendered":"

REQUEST_IRQ<\/h1>\n

NAME<\/a>
SYNOPSIS<\/a>
DESCRIPTION<\/a>
RETURN VALUE<\/a>
AVAILABILITY<\/a>
SEE ALSO<\/a>
AUTHOR<\/a>
BUGS<\/a> <\/p>\n

\n

NAME <\/a> <\/h2>\n

request_irq, free_irq \u2212 register an interrupt handler<\/p>\n

SYNOPSIS <\/a> <\/h2>\n

#include
#include #include #include <\/b><\/p>\n\n\n
<\/td>\n\n

int request_irq(unsigned\u00a0int\u00a0<\/b>irq<\/i>, void\u00a0(*<\/b>handler<\/i>)(int,\u00a0void\u00a0*,\u00a0struct\u00a0pt_regs\u00a0*), unsigned\u00a0long<\/b> irqflags<\/i>, const\u00a0char\u00a0*<\/b>devname<\/i>, void\u00a0*<\/b>dev_id<\/i>);<\/b><\/p>\n<\/td>\n<\/tr>\n<\/table>\n

void\u00a0free_irq(unsigned\u00a0int<\/b> irq<\/i>, void\u00a0*<\/b>dev_id<\/i>);<\/b><\/p>\n

DESCRIPTION <\/a> <\/h2>\n

Usage<\/b>
The request_irq()<\/b> function requests that a specified function (the handler) be called whenever the kernel receives a given interrupt. The handler may in turn register a bottom half, which is usually a slower part of the handler which does not need to be executed as soon as the interrupt is received. See init_bh<\/b>(9) for more information on bottom halves.<\/p>\n

The irq<\/i> parameter is the interrupt number you want to handle. It must be less than NR_IRQS<\/b> (16 on Intel systems), and there may be additional limitations on the value. See arch\/*\/kernel\/irq.c<\/i> (intr.c<\/i> on m68k machines) for more information.<\/p>\n

handler<\/i> is a pointer to the a pointer to the function that will handle the interrupt. The handler is passed the following parameters:<\/p>\n

int<\/b> irq<\/i><\/p>\n

The interrupt number. By testing the value of this parameter, it is possible for a single function to handle multiple IRQs.<\/p>\n

void *<\/b>dev_id<\/i><\/p>\n

The device ID of this handler (see below).<\/p>\n

struct pt_regs *<\/b>regs<\/i><\/p>\n

The registers stored on the stack of the process that was interrupted. Normally, one shouldn\u2019t mess with these, although they can be read to determine, for example, whether the interrupted process was in kernel or user mode.<\/p>\n

irqflags<\/i> is, as the name suggests, a bitmask of flags pertaining to this interrupt handler. Legal bits are:<\/p>\n

SA_INTERRUPT<\/b><\/p>\n

This bit indicates that you are registering a fast interrupt handler. The semantics of this are discussed below.<\/p>\n

SA_SHIRQ<\/b><\/p>\n

This bit indicates that your handler supports sharing an IRQ with other handlers (see also *dev_id<\/i> below).<\/p>\n

SA_SAMPLE_RANDOM<\/b><\/p>\n

This bit indicates that this IRQ may be used as an entropy source for \/dev\/random<\/i> and \/dev\/urandom<\/i> (see drivers\/char\/random.c<\/i>).<\/p>\n

SA_PROBE<\/b><\/p>\n

This bit indicates that the IRQ is being probed and that the handler being installed is not a real one. It was intended that this value be used internally by probe_irq_on()<\/b> (q.v.), but it is no longer used in 2.1.x kernels. In fact, even with 2.0.x kernels, it is only used by the MIPS architecture. You should not be using this value unless you know what you are doing.<\/p>\n

SA_STATIC_ALLOC<\/b><\/p>\n

(Sparc\/Sparc64 only) This bit requests that your struct irqaction<\/b> (see below) be added to a statically allocated array of four handlers, rather than the normal irq_action[]<\/b> table. This is used for IRQs that must be requested early in the boot process, before kmalloc_init()<\/b> has been called.<\/p>\n

The devname<\/i> parameter is a short name for the device and is displayed in the \/proc\/interrupts<\/i> list.<\/p>\n

The dev_id<\/i> parameter is the device ID. This parameter is usually set to NULL, but should be non-null if you wish to do IRQ sharing. This doesn\u2019t matter when hooking the interrupt, but is required so that, when free_irq()<\/b> is called, the correct driver is unhooked. Since this is a void *<\/b>, it can point to anything (such as a device-specific structure, or even empty space), but make sure you pass the same pointer to free_irq()<\/b>.<\/p>\n

The free_irq()<\/b> function releases an interrupt handler from operation. It takes as parameters the IRQ to unregister, and the device ID of the handler to be unregistered. You should pass the same values here as you did to request_irq()<\/b>. You probably shouldn\u2019t unregister other people\u2019s interrupt handlers unless you know what you are doing.<\/p>\n

Operation<\/b>
For most architectures, request_irq()<\/b> operates by allocating memory for a struct irqaction<\/b>, filling out the fields thereof, and adding it to the irq_action[]<\/b> table. enable_irq()<\/b> is then called, which simply tells the kernel to start delivering interrupts to the installed handler. This process is vastly different on m68k machines, where it varies depending on what type of machine (Amiga, Atari, etc.) one is using. free_irq()<\/b> simply removes the entries that request_irq()<\/b> added. Note that some of these names differ depending on the architecture (for example, struct irqaction<\/b> is known as struct irq_action<\/b> on the Power PC). If you need to know more about the internal workings of these functions, you are best off reading the source, as some of this information may have changed by the time you read this (if so, tell me, so I can try to update this page).<\/p>\n

Fast Interrupt Handlers<\/b>
A \u2018fast\u2019 interrupt handler (one with SA_INTERRUPT<\/b> set) has the following differences from normal \u2018slow\u2019 interrupt handlers:<\/p>\n

On the ix86 and MIPS, the handler is called with interrupts disabled (they are enabled by default on these machines; on other machines, they are disabled by default).<\/p>\n

On the MIPS, a faster return is used.<\/p>\n

On the Alpha, MIPS, Sparc, and Sparc64, a fast and a slow handler may not share the same IRQ.<\/p>\n

On all architectures except the m68k and the ix86, a \u2018+\u2019 is displayed between the interrupt count and the device name in \/proc\/interrupts<\/i>.<\/p>\n

The slow-versus-fast interrupt distinction is slowly being phased out. For example, under 2.0.x on the ix86, SA_INTERRUPT<\/b> enabled a fast return as it still does on the MIPS; this distiction was removed in 2.1.x.<\/p>\n

RETURN VALUE <\/a> <\/h2>\n

On success, request_irq()<\/b> returns 0 if everything goes as planned. Your interrupt handler will start receiving its interrupts immediately. On failure, request_irq()<\/b> returns:<\/p>\n

-EINVAL<\/b><\/p>\n

The IRQ number you requested was either invalid or reserved, or your passed a NULL pointer for the handler()<\/i> parameter.<\/p>\n

-ENOMEM<\/b><\/p>\n

request_irq()<\/b> could not allocate enough memory for something (probably the struct irqaction<\/b>).<\/p>\n\n\n\n
<\/td>\n\n

-EBUSY<\/b><\/p>\n<\/td>\n

<\/td>\n\n

The IRQ you requested is already being handled, and the IRQ cannot be shared. This can occur because either the handler being registered or the handler already present does not have SA_SHIRQ<\/b> in its irqflags<\/i> field. In addition, on most architectures, all handlers sharing a single IRQ must be of the same speed; i.e., either all or none of them may have the SA_INTERRUPT<\/b> flag set. Finally, it is possible that your architecture may not support sharing of the IRQ you are attempting to use.<\/p>\n<\/td>\n<\/tr>\n

<\/td>\n\n

-ENXIO<\/b><\/p>\n<\/td>\n

<\/td>\n\n

The m68k returns this value for an invalid IRQ number.<\/p>\n<\/td>\n<\/tr>\n<\/table>\n

free_irq()<\/b> does not return a value.<\/p>\n

AVAILABILITY <\/a> <\/h2>\n

Linux 2.1+. The information on this page should work for 2.0.x, but there may be subtle differences (for example, the semantics of SA_INTERRUPT<\/b> on Intel-based machines). Versions earlier than 2.0 had these functions, but the dev_id<\/i> parameter was missing. If you want your code to work with versions both earlier and later than 2.0, you should protect your code with preprocessor macros using LINUX_VERSION_CODE<\/b>.<\/p>\n

SEE ALSO <\/a> <\/h2>\n

init_bh<\/b>(9), probe_irq_on<\/b>(9), arch\/*\/kernel\/irq.c<\/i>, arch\/*\/kernel\/entry.S<\/i>, include\/linux\/interrupt.h<\/i>, include\/asm*\/signal.h<\/i>.<\/p>\n

AUTHOR <\/a> <\/h2>\n

Neil Moore <amethyst@maxwell.ml.org<\/i>><\/p>\n

BUGS <\/a> <\/h2>\n

It\u2019s not exactly a bug, but request_irq()<\/b> on the m68k is very<\/i> strange compared to the same function on the other supported architectures. You should really read arch\/m68k\/kernel\/ints.c<\/i>, arch\/m68k\/atari\/ataints.c<\/i>, arch\/m68k\/amiga\/amiints.c<\/i>, and arch\/m68k\/amiga\/cia.c<\/i> if you plan on writing drivers for any of these systems.<\/p>\n

\n","protected":false},"excerpt":{"rendered":"

request_irq, free_irq \u2212 register an interrupt handler <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1222],"tags":[1226,1223,1225,1255],"class_list":["post-4175","post","type-post","status-publish","format-standard","hentry","category-9-rutinas-del-nucleo","tag-1226","tag-kernel","tag-man9","tag-request_irq"],"gutentor_comment":0,"_links":{"self":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts\/4175","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/comments?post=4175"}],"version-history":[{"count":0,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts\/4175\/revisions"}],"wp:attachment":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/media?parent=4175"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/categories?post=4175"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/tags?post=4175"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}