SA_INTERRUPT or SA_SHIRQ

Hi All,

My comments inline

   can you please tell me your kernel version?

It's linux 2.6.10

   SA_INTERRUPT is deprecated for many years. it is changed to be
IRQF_DISABLED, which is also deprecated since 2.6.35.
   in kernel 2.6.35, top half interrupt handler will be called with
interrupts disabled,

   and for SA_SHIRQ, it is changed to be IRQF_SHARED, you should check the
return value of request_irq() to see whether your irq can be shared with
former
   registered irq which use the same int line. suppose you are registering
irq19 for usb, and the BT module has reigstered irq19 with IRQF_SHARED
flag, then you are lucky enough to reigter correctly for usb. opposite, if
BT module registered irq19 without IRQF_SHARED flag, then BT will use irq19
alone, it means your register for usb will fail .

request_irq(  irq, soc_intr, SA_INTERRUPT | SA_SHIRQ,
                      MODULE_NAME, dev);

I am assuming that when I specify both SA_INTERRUPT and SA_SHIRQ in
request_irq then there are 3 possibilities:

1. If the 'irq' is free then I will be granted the line in SA_INTERRUPT
mode i.e all the other maskable interrupts will be disabled when
      my top_half is executing.

2. If the 'irq' is already granted to some other device in SA_SHIRQ mode
then I will also get it in SA_SHIRQ mode i.e all the maskable
    interrupts enabled execpt from the device whose ISR Top_half is
executing.

3. If the 'irq' is already granted to some other device in SA_INTERRUPT
mode then my request_irq will fail.


I hope this is the right assumption just my only doubt is does the above
behavior in any way depends on the CPU arch. i.e is it different for x86
and PPC ?


Regards,
Devendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120223/64d2ba37/attachment-0001.html