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

[marc.zyngier@arm.com (Marc Zyngier)]

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.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...