Re: [patch 03/32] genirq: Provide generic hwirq allocation facility

[Chris Metcalf <cmetcalf@tilera.com>]

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