[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1r5oiv5ja.fsf@fess.ebiederm.org>
Date: Thu, 18 Feb 2010 09:04:57 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Yinghai Lu <yinghai@...nel.org>
Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Suresh Siddha <suresh.b.siddha@...el.com>,
linux-kernel@...r.kernel.org, Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [RFC PATCH 3/3] genericirq: change ack/mask in irq_chip to take irq_desc in addition to irq
Yinghai Lu <yinghai@...nel.org> writes:
> will have
> void (*ack)(unsigned int irq, struct irq_desc *desc);
> void (*mask)(unsigned int irq, struct irq_desc *desc);
> void (*mask_ack)(unsigned int irq, struct irq_desc *desc);
> void (*unmask)(unsigned int irq, struct irq_desc *desc);
> void (*eoi)(unsigned int irq, struct irq_desc *desc);
>
> so for sparseirq with raidix tree, we don't call extra irq_to_desc, and could use desc directly
This doesn't look bad.
May I ask why these methods and why pass both irq and desc instead of
just desc?
I think in the long run passing both irq and desc through several
functions may incur some maintenance cost that it would be nice not to
pay (register pressure and increased chance of typos).
With a big sweeping change like this I want to be certain we won't
change our minds and come back and want to change it all again.
Oh and a multiarch patch like this should really cc linux-arch
so the arch maintainers can see it.
In passing it looks like want to transform get_irq_data in hpet.c to
get_irq_desc_data.
Eric
--
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