summaryrefslogtreecommitdiffstats
path: root/arch/powerpc/configs/maple_defconfig
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2013-07-01 22:14:10 +0200
committerThomas Gleixner <tglx@linutronix.de>2013-07-02 14:26:45 +0200
commit07bd1172902e782f288e4d44b1fde7dec0f08b6f (patch)
treef5d0913e170ce7efff96512a90f310b3f43530f9 /arch/powerpc/configs/maple_defconfig
parenttick: Prevent uncontrolled switch to oneshot mode (diff)
downloadlinux-07bd1172902e782f288e4d44b1fde7dec0f08b6f.tar.xz
linux-07bd1172902e782f288e4d44b1fde7dec0f08b6f.zip
tick: Sanitize broadcast control logic
The recent implementation of a generic dummy timer resulted in a different registration order of per cpu local timers which made the broadcast control logic go belly up. If the dummy timer is the first clock event device which is registered for a CPU, then it is installed, the broadcast timer is initialized and the CPU is marked as broadcast target. If a real clock event device is installed after that, we can fail to take the CPU out of the broadcast mask. In the worst case we end up with two periodic timer events firing for the same CPU. One from the per cpu hardware device and one from the broadcast. Now the problem is that we have no way to distinguish whether the system is in a state which makes broadcasting necessary or the broadcast bit was set due to the nonfunctional dummy timer installment. To solve this we need to keep track of the system state seperately and provide a more detailed decision logic whether we keep the CPU in broadcast mode or not. The old decision logic only clears the broadcast mode, if the newly installed clock event device is not affected by power states. The new logic clears the broadcast mode if one of the following is true: - The new device is not affected by power states. - The system is not in a power state affected mode - The system has switched to oneshot mode. The oneshot broadcast is controlled from the deep idle state. The CPU is not in idle at this point, so it's safe to remove it from the mask. If we clear the broadcast bit for the CPU when a new device is installed, we also shutdown the broadcast device when this was the last CPU in the broadcast mask. If the broadcast bit is kept, then we leave the new device in shutdown state and rely on the broadcast to deliver the timer interrupts via the broadcast ipis. Reported-and-tested-by: Stehle Vincent-B46079 <B46079@freescale.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Cc: John Stultz <john.stultz@linaro.org>, Cc: Mark Rutland <mark.rutland@arm.com> Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1307012153060.4013@ionos.tec.linutronix.de Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'arch/powerpc/configs/maple_defconfig')
0 files changed, 0 insertions, 0 deletions