[PATCH Precise SRU] tick: Fix the spurious broadcast timer ticks after resume

[Seth Forshee]

On Fri, Oct 12, 2012 at 12:32:53PM -0600, Tim Gardner wrote:
> From: Suresh Siddha <suresh.b.siddha at intel.com>
> 
> BugLink: http://bugs.launchpad.net/bugs/1065076
> 
> During resume, tick_resume_broadcast() programs the broadcast timer in
> oneshot mode unconditionally. On the platforms where broadcast timer
> is not really required, this will generate spurious broadcast timer
> ticks upon resume. For example, on the always running apic timer
> platforms with HPET, I see spurious hpet tick once every ~5minutes
> (which is the 32-bit hpet counter wraparound time).
> 
> Similar to boot time, during resume make the oneshot mode setting of
> the broadcast clock event device conditional on the state of active
> broadcast users.
> 
> Signed-off-by: Suresh Siddha <suresh.b.siddha at intel.com>
> Tested-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> Tested-by: svenjoac at gmx.de
> Cc: torvalds at linux-foundation.org
> Cc: rjw at sisk.pl
> Link: http://lkml.kernel.org/r/1334802459.28674.209.camel@sbsiddha-desk.sc.intel.com
> Signed-off-by: Thomas Gleixner <tglx at linutronix.de>
> (cherry picked from commit a6371f80230eaaafd7eef7efeedaa9509bdc982d)
> 
> Signed-off-by: Tim Gardner <tim.gardner at canonical.com>

I'm rather confused.

The bug report is about a failure to resume, but the commit message
describes fixing a spurious timer interrupt. On the bug the reporter
states that upstream kernel 3.6 is still affected, and this patch was
merged during 3.4. There's also no verification that I can see that
backporting this patch to 3.2 fixes the issue.

So how did you arrive at the conclusion that this patch fixes the bug?