Messages in this thread | | | Date | Wed, 18 Mar 2009 14:00:56 +0200 | From | Felipe Balbi <> | Subject | Re: [patch/rfc 1/2] GENIRQ: add handle_threaded_irq() flow handler |
| |
Hi,
On Wed, Mar 18, 2009 at 03:19:47AM +0100, David Brownell wrote:
[..]
> @@ -295,6 +295,67 @@ static inline void mask_ack_irq(struct i > } > > /** > + * handle_threaded_irq - flow handler reusing current irq thread > + * @irq: the interrupt number > + * @desc: the interrupt description structure for this irq > + * Context: irq thread, with IRQs enabled > + * > + * IRQ threads which demultiplex IRQs may use this flow handler > + * to chain those demultiplexed IRQs to subsidiary handlers, when > + * all that IRQ dispatch logic must run in sleeping contexts. > + * > + * Examples include some multifunction I2C and SPI based devices > + * (where access to registers, including ones involved in IRQ > + * dispatching, requires sleeping) that have multiple independent > + * maskable interupts. > + * > + * The irq thread using this flow handler must handle any ack, > + * clear, mask or unmask issues needed. > + */ > +void > +handle_threaded_irq(unsigned int irq, struct irq_desc *desc) > +{ > + struct irqaction *action; > + irqreturn_t action_ret; > + > + spin_lock_irq(&desc->lock); > + > + if (unlikely(desc->status & IRQ_INPROGRESS)) > + goto out_unlock; > + desc->status &= ~(IRQ_REPLAY | IRQ_WAITING); > + kstat_incr_irqs_this_cpu(irq, desc); > + > + action = desc->action; > + if (unlikely(!action || (desc->status & IRQ_DISABLED))) > + goto out_unlock;
you say below irqs are always enabled so this branch is something we never want to happen. How about adding a WARN() then ?
-- balbi
| |