On Mon, May 23, 2016 at 05:59:37PM -0300, Fabio Estevam wrote:

On Mon, May 23, 2016 at 5:23 PM, Rafael J. Wysocki [off-list ref] wrote:

quoted

For one, if that platform is not capable of raising interrupts for IRQ
works, I'm not sure why arch_irq_work_has_interrupt() returns true on
it.

It returns true because the kernel was built with CONFIG_SMP=y.

On ARM we have:

static inline bool arch_irq_work_has_interrupt(void)
{
    return is_smp();
}

and then:

static inline bool is_smp(void)
{
#ifndef CONFIG_SMP
    return false;
#elif defined(CONFIG_SMP_ON_UP)
    extern unsigned int smp_on_up;
    return !!smp_on_up;
#else
    return true;
#endif
}

So if CONFIG_SMP=y,  is_smp() returns 1.

As I mentioned before, the reboot problem does not happen with CONFIG_SMP=n.

Read the code again.  There's three states:

1. CONFIG_SMP=n - it always returns false.
2. CONFIG_SMP=y, CONFIG_SMP_ON_UP=n - it always returns true.  Such a
   kernel can _only_ be run on SMP capable systems.
3. CONFIG_SMP=y, CONFIG_SMP_ON_UP=y - it returns depending on whether
   we detect that the CPU is SMP capable.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.