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

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

On 17/08/16 08:58, Peter Chen wrote:
>  
>> On 17/08/16 04:15, Peter Chen wrote:
>>> On Tue, Aug 16, 2016 at 11:26 PM, Marc Zyngier <marc.zyngier@arm.com>
>> wrote:
>>>> Not all of the ARM HW is IPI capable (i.e. most of the non-SMP
>>>> systems). Unfortunately, some systems do advertise being SMP capable,
>>>> even if they have a single core and do not define a cross call
>>>> method.
>>>
>>> Could you example it? I find all current set_smp_cross_call is defined
>>> under CONFIG_SMP.
>>
>> This doesn't mean that the system will be SMP at runtime (SMP_ON_UP).
>>
>  
> I am puzzled that how you would like to check IPI capable, at runtime
> or according to kernel configuration?
> 
>>>>
>>>>  static inline bool arch_irq_work_has_interrupt(void)  {
>>>> -       return is_smp();
>>>> +#ifdef CONFIG_SMP
>>>
>>> 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.

Thanks,

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