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

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

On 17/08/16 12:27, Peter Chen wrote:
>>
>> 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.

Look, we've been there before. For your platform to work with your
configuration, you need the GIC patch that I already posted, and that
has been tested by Fabio Estevam on the same A7 platform.

The patch you are replying to handles a different case, which is the one
where the HW is advertised as being SMP-capable, and yet do not have an
IPI-capable interrupt controller.

I can't make it clearer, sorry.

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