[PATCH] ARM: irq_work: Do not attempt to IPI on non IPI-capable HW
Marc Zyngier
marc.zyngier at arm.com
Wed Aug 17 02:19:20 PDT 2016
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...
More information about the linux-arm-kernel
mailing list