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