Messages in this thread | | | Date | Mon, 22 Mar 2010 15:16:30 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH 05/10] x86: use vector_desc instead of vector_irq |
| |
> >> -typedef int vector_irq_t[NR_VECTORS]; > >> -DECLARE_PER_CPU(vector_irq_t, vector_irq); > >> -extern void setup_vector_irq(int cpu); > >> +typedef struct irq_desc *vector_desc_t[NR_VECTORS]; > > > > Why do we need that typedef ? Please use plain struct irq_desc * > > Well at least originally DECLARE_PER_CPU chocked when given a complex > type. Does: > DECLARE_PER_CPU(struct irq_desc *[NR_VECTORS], vector_desc); > work?
Hmm, I thought that was fixed, but I might be wrong as usual.
> > >> +DECLARE_PER_CPU(vector_desc_t, vector_desc); > >> +extern void setup_vector_desc(int cpu); > > ... > >> void destroy_irq(unsigned int irq) > >> { > >> unsigned long flags; > >> + struct irq_desc *desc; > >> + struct irq_cfg *cfg; > >> > >> dynamic_irq_cleanup_keep_chip_data(irq); > >> > >> free_irte(irq); > >> raw_spin_lock_irqsave(&vector_lock, flags); > >> - __clear_irq_vector(irq, get_irq_chip_data(irq)); > >> + desc = irq_to_desc(irq); > >> + cfg = desc->chip_data; > >> + __clear_irq_vector(desc, cfg); > > > > __clear_irq_vector(desc, desc->chip_data); > > > > should be sufficient, right ? > > You want to deliberately loose a modicum of type safety?
I really have a hard time to see how assigning a void pointer to a struct irq_cfg pointer is anymore type safe than using the void pointer as for the function argument right away.
> >> if (printk_ratelimit()) > >> - pr_emerg("%s: %d.%d No irq handler for vector (irq %d)\n", > >> - __func__, smp_processor_id(), vector, irq); > >> + pr_emerg("%s: %d.%d No irq handler for vector\n", > > > > That printk is confusing. It's not lacking an irq handler. The > > vector is simply not assigned. > > Long evolution. Do you have a suggestion of better wording?
You mean hysterical raisins. Ok, how about:
pr_emerg("irq: %d.d irq vector not assigned\n", ...);
Thanks,
tglx
| |