From mboxrd@z Thu Jan 1 00:00:00 1970 From: marc.zyngier@arm.com (Marc Zyngier) Date: Wed, 17 Aug 2016 09:08:48 +0100 Subject: [PATCH] ARM: irq_work: Do not attempt to IPI on non IPI-capable HW In-Reply-To: References: <1471361210-29914-1-git-send-email-marc.zyngier@arm.com> <57B41523.6030202@arm.com> Message-ID: <57B41B90.3050204@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 >> 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...