Messages in this thread | | | Date | Thu, 26 Jun 2003 12:13:18 +0100 | From | Christoph Hellwig <> | Subject | Re: [PATCH][RFC] irq handling code consolidation (common part) |
| |
> +#ifndef HAVE_ARCH_IRQ_DESC > + > +/* > + * Controller mappings for all interrupt sources: > + */ > +irq_desc_t irq_desc[NR_IRQS] __cacheline_aligned = { > + [0 ... NR_IRQS - 1] = { > + .handler = &no_irq_type, > + .lock = SPIN_LOCK_UNLOCKED, > + } > +}; > + > +#endif
What about getting rid of that ifdef and having irq_desc always in arch code? Seems a lot cleaner to me.
> +#if defined(CONFIG_SMP) && !defined(HAVE_ARCH_SYNCRONIZE_IRQ) > + > +inline void synchronize_irq(unsigned int irq) > +{ > + irq_desc_t *desc = irq_desc(irq); > + > + /* is there anything to synchronize with? */ > + if (!desc->action) > + return; > + > + while (desc->status & IRQ_INPROGRESS) > + cpu_relax(); > +} > + > +#endif
Hmm, what arch can't use the generic version and why? I really don't like the HAVE_ARCH_ macros if there's a way around it.
> +#ifndef HAVE_ARCH_IRQ_PROC > +void register_irq_proc(unsigned int irq); > +#endif
Again, what arch can't use the generic code?
> +#ifndef HAVE_ARCH_IRQ_PROBE > + > +/* > + * IRQ autodetection code.. > + * > + * This depends on the fact that any interrupt that > + * comes in on to an unassigned handler will get stuck > + * with "IRQ_WAITING" cleared and the interrupt > + * disabled. > + */
Which architecture uses it's own version here? Also we might move this to a separate file as it doesn't make a lot of sense without CONFIG_ISA
Otherwise it looks fine (of course)! Let's hope we'll get some variant of it in before 2.6. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |