Linux Interrupt Context maps to ARM CPSR.mode = IRQ

[Mj Embd]

On Fri, May 2, 2014 at 7:17 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 2014-05-02 13:34, Mj Embd wrote:
>>
>> Adding Marc to comment
>> Marc Please clarify the doubt
>>
>>
>>
>> On Fri, May 2, 2014 at 5:15 PM, Mj Embd <mj.embd at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> As per a lot of linux documentation some components work in process
>>> context and some work in interrupt context.
>>>
>>> If we try to map these contexts to ARM processor modes then is it
>>> safely to assume that
>>> Process Context : CPSR.mode = SVC
>>> Interrupt Context : CPSR.mode = IRQ
>>>
>>> If not how to define interrupt context properly. Confusing at times.
>
>
> Well, none of this is completely true.
>
> Process context exists both in USR (process in user mode) and SVC (process
> in kernel mode, executing a syscall for example).
>
> As for interrupts, the processor indeed starts executing the interrupt in
> IRQ mode, but this is a useless complication as far as Linux is concerned,

I didn't understood the term useless here, I hope it is not about the
question itself.

> and we quickly switch to SVC (see the definition of the vector_stub macro in
> arch/arm/kernel/entry-armv.S).
>
So what is the mode of the processor when Linux is executing in the
Academic / Bookish Term "Interrupt Context"
There is a function called in_interrupt which tells if linux is in
interrupt context.
But How to define/quantify Interrupt Context as a whole

Also, Some texts say there are two contexts Hard IRQ Context , Soft IRQ Context.
HardIRQ = interrupts Disabled , (possibly CPSR.I=1, mode=IRQ)
SoftIRQ = interrupts Enabled , (possibly CPSR.I=0, mode=IRQ)

SoftIRQs when executed from Ksoftirqd daemon  (possibly CPSR.I=0, mode=SVC)

We have a client query on this.

> Hope this helps.
>
>         M.
> --
> Fast, cheap, reliable. Pick two.



-- 
-mj