[PATCH] ARM: irq_work: Do not attempt to IPI on non IPI-capable HW

[Peter Chen]

>
>On 17/08/16 09:28, Peter Chen wrote:
>>
>>>>>>
>>>>>> Why not using is_smp as condition, it is more strict.
>>>>>>
>>>>>> if (is_smp())
>>>>>>     return !!__smp_cross_call;
>>>>>> else
>>>>>>     return false;
>>>>>
>>>>> What's the gain? We're trying to check whether we can actually
>>>>> deliver an IPI. Why should we gate it by finding out whether we're
>>>>> smp_on_up or
>>> not?
>>>>>
>>>>
>>>> If UP system with CONFIG_SMP enabled, the __smp_cross_call is not
>>>> NULL, but the IPI is not capable. Or am I missing something?
>>>
>>> Take an OMAP3 system. It is UP,  and doesn't have a GIC, so
>>> __smp_cross_call will be NULL. Yet, it boots with a generic multi-platform kernel,
>with SMP on.
>>>
>>
>> Are there any UP platforms which have GIC? If there is, we may be in
>> trouble with only depends on CONFIG_SMP.
>
>Why would we be in trouble? Things will still work, as the irq work will be taken care
>of on the next timer interrupt. Again: the self IPI is only a latency optimization.
>

>From what I see, it is different with you. arch_irq_work_raise will be called if 
irq work is not lazy, and  If arch_irq_work_has_interrupt() is true,
the system will try to call IPI_IRQ_WORK through the GIC, but GIC has no
IPI capabilities, then the system is stuck, this is the same we have observed
at A7 single core platform.

Peter