On 2 October 2013 20:31, Will Deacon <[email protected]> wrote: > On Wed, Oct 02, 2013 at 06:19:30PM +0100, Taras Kondratiuk wrote: >> On 2 October 2013 15:49, Will Deacon <[email protected]> wrote: >> > On Wed, Oct 02, 2013 at 12:34:16PM +0100, Taras Kondratiuk wrote: >> >> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c >> >> index 94f6b05..e359b62 100644 >> >> --- a/arch/arm/kernel/process.c >> >> +++ b/arch/arm/kernel/process.c >> >> @@ -103,9 +103,11 @@ void soft_restart(unsigned long addr) >> >> local_irq_disable(); >> >> local_fiq_disable(); >> >> >> >> - /* Disable the L2 if we're the last man standing. */ >> >> - if (num_online_cpus() == 1) >> >> + /* Flush and disable the L2 if we're the last man standing. */ >> >> + if (num_online_cpus() == 1) { >> >> + outer_flush_all(); >> >> outer_disable(); >> > >> > l2x0_disable already contains a flush, so this doesn't change anything. >> >> Unfortunately not everybody uses l2x0_disable(). >> SoC's that use SMC calls for L2 cache maintenance have its own implementation >> of outer_cache.disable which usually doesn't flush cache implicitly. > > In which case, we should probably fix the disabling code to make a flush > then update callers not to bother with redundant flushing. The flushing > during the disable code is likely required anyway if there's any > synchronisation going on.
It makes sense, but a history of the current code looks a bit confusing. Implicit flush was added in l2x0_disable() as a "side effect" of commit 38a8914f9ac2379293944f613e6ca24b61373de8 "ARM: 6987/1: l2x0: fix disabling function to avoid deadlock", while initially disable was just a disable. Maybe it worth to explicitly document that .disable callback must flush cache? -- Regards, Taras Kondratiuk -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
