| Date | Wed, 14 May 2014 13:57:32 -0400 | From | Chris Metcalf <> | Subject | Re: [patch 03/32] genirq: Provide generic hwirq allocation facility |
| |
On 5/7/2014 7:15 PM, Thomas Gleixner wrote: > On Wed, 7 May 2014, Chris Metcalf wrote: >> We have an internal change that we haven't upstreamed yet that makes >> irqs actually (cpu,ipi) pairs, so that more irqs can be allocated. >> As a result we allocate some irqs as bound to a specific IPI on a single >> cpu, and some irqs get bound to a particular IPI registered on every cpu. >> >> I'll have to set aside a bit of time to look more closely at how your >> change interacts with the work we've done internally. I've appended the >> per-cpu IRQ change from our internal tree here (and cc'ed the author). >> The API change is in the <asm/irq.h> diff at the very start. > Sure it'll break it. [...]
I think the right thing for now is to take my Acked-by for the tile changes (given a couple of minor nits replied to in separate emails).
Acked-by: Chris Metcalf <cmetcalf@tilera.com>
When we have the chance to set aside some time for more upstreaming of some of the work we've done it does seem like it makes sense to tackle doing some kind of matrix mapping in a more generic way.
You're probably right that a cpumask approach would have made more sense than a cpu integer in the tile API, so we'd certainly go with that in any fgeneric matrix mapping code.
I do have one question about the irq_alloc_hwirqs() API, which is the use of zero as an error indicator. Given that zero can plausibly be an IRQ number, it seems cleaner to specify this as returning a negative errno failure instead. Doing so would also align with __irq_alloc_descs(). So, what was your thinking around using zero?
-- Chris Metcalf, Tilera Corp. http://www.tilera.com
|