[PATCH] ARM: GIC: dont warn on pre-allocated IRQ descs

[Rob Herring]

On 09/25/2012 03:08 PM, Linus Walleij wrote:
> On Tue, Sep 25, 2012 at 9:28 PM, Rob Herring <robherring2 at gmail.com> wrote:
>> On 09/25/2012 02:19 PM, Linus Walleij wrote:
> 
>>> The allocation will succeed if the platform define .nr_irqs
>>> to 0 as an ideal device tree platform would do, but I think it
>>> is a bit thick to require that every platform that wants to
>>> use sparse IRQs must first or simultaneously switch to
>>> device tree. So make this to a simple pr_debug().
>>
>> It's not a matter of switching to DT or not. It is a matter of whether
>> an irq_chip allocates it's descriptors or not either directly or
>> indirectly via irqdomain.
> 
> Yeah OK that's true.
> 
>> The gic does this, so it is secondary
>> controllers which are the problem. A platform could allocate the ranges
>> needed for those controllers and leave a hole for the gic to allocate.
>>
>> A prefer to leave this so platforms get fixed.
> 
> Since the core kernel will allocate .nr_irqs on boot I guess
> this means you have to define the machine's .nr_irqs to
> zero or atleast < 16 so it doesn't overlap with those the
> GIC wants to use.

I believe the default of 0 causes NR_IRQS_LEGACY to be used which is
what we want.

> So I'll try that, and ad-hoc allocate descriptors needed
> above that range for drivers that are not yet allocating
> their descriptors ...
> 
> One question though: the real fix is obviously for all
> drivers exposing an irqchip to allocate its descriptors
> dynamically with exlicit alloc_descs() or using the
> linear irq domain instead of relying on pre-allocated
> descriptors.
> 
> Should we patch all drivers to spit out similar warnings
> then?

If you are bored with nothing else to do... Might as well fix them if
you can find them all.

Of course if you follow my previous suggestion, that would be a red flag
that you aren't fixing the irq_chip and we should reject the change. :)

Rob

> 
> Yours,
> Linus Walleij
>