[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1109071924510.2723@ionos>
Date: Wed, 7 Sep 2011 19:31:58 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: David Miller <davem@...emloft.net>
cc: yong.zhang0@...il.com, linux-kernel@...r.kernel.org, mingo@...e.hu,
joe@...ches.com, sparclinux@...r.kernel.org
Subject: Re: [PATCH 20/62] sparc: irq: Remove IRQF_DISABLED
On Wed, 7 Sep 2011, David Miller wrote:
> From: Yong Zhang <yong.zhang0@...il.com>
> Date: Wed, 7 Sep 2011 16:10:17 +0800
>
> > This flag is a NOOP and can be removed now.
> >
> > Signed-off-by: Yong Zhang <yong.zhang0@...il.com>
>
> How are things working now, if that is the case?
>
> Specifically in the ldc_bind() case, we're passing iRQF_DISABLED here
> so that the IRQ is not turned on when we request the IRQ, we later do
> enable_irq() on these after we've take the spinlock in this function.
>
> The IRQ cannot be allowed to be delivered between the request_irq()
> call and the enable_irq() calls.
>
> This sequence is necessary to deal with some lock ordering issues.
IRQF_DISABLED was telling the core code that the interrupt must run
with interrupts disabled. As we enforced running all handlers with
interrupts disabled the flag is meaningless. It was defined as 0
anyway.
What you need to prevent that request_irq() enables the interrupt
unconditionally, is to set IRQ_NOAUTOEN on the interrupt, which can't
be handed in to request_irq(). You want to call
irq_set_status_flags(irq, IRQ_NOAUTOEN);
for that irq. That tells request_irq() to leave the interrupt disabled
and you have to explicitely enable it. That has not changed since we
generalized the irq core code back in 2006.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists