> > > Usually what you pass is actually the device structure for > your device, > not null. And you can use that to find the io addresses etc > etc of the > exact device in question > > <Raja> So we should not pass NULL even if the handler does not > share the IRQ with any other handler ? <Raja> correct > > 2. Also as the dev_id is passed to the interrupt handler > when > > it is invoked , why should the kernel call all handlers on a > > particular IRQ ? Rather, it can call the handler which has > > registered for that device ? > > you don't know which device generated the irq! > All the kernel knows is that "irq 11 triggered". Not which of > the two > devices on irq 11 did that. > > > > > <Raja> My question is if the kernel is going to call the > handler with the correct dev_id parameter, then why should the > handler again check if its device caused the IRQ ? > It has the dev_id of the device. So it knows the device which > caused the IRQ. right ? > > Or is it like, the kernel will call a handler with the dev_id > passed to it during registration, and not with the dev_id of > the device which actually caused the IRQ ? <Raja> correct again. With 2 devices sharing the same irq number (again think of that serial card and ide controller) the kernel DOES NOT KNOW which one of the two caused the irq, only that it was irq 11. The only one who can know if it was their irq is the irq handlers themselves, so the kernel calls the serial card handler with the dev_id passed at registration of the serial card irq handler, and the ide controller irq handler with the dev_id passed at that registration. Eg think of your irq handler being called as "Something happened. We think it MAY have been you, but it may have been something else as well. Please check and act if it was you" -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
