SA_INTERRUPT or SA_SHIRQ

[devendra rawat]

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