gpio/omap: fix broken context restore for non-OFF mode transitions
authorKevin Hilman <khilman@ti.com>
Thu, 17 May 2012 21:52:56 +0000 (14:52 -0700)
committerKevin Hilman <khilman@ti.com>
Fri, 18 May 2012 14:01:44 +0000 (07:01 -0700)
commit22770de11cb13e7120f973bca6c800de371a6717
tree9d6005623b3bff119e3f31d23512e893fd929de3
parent1b1287032df3a69d3ef9a486b444f4ffcca50d01
gpio/omap: fix broken context restore for non-OFF mode transitions

The fix in commit 1b1287032 (gpio/omap: fix missing check in
*_runtime_suspend()) exposed another bug in the context restore path.

Currently, the per-bank context restore happens whenever the context
loss count is different in runtime suspend and runtime resume *and*
whenever the per-bank contex_loss_count == 0:

if (context_lost_cnt_after != bank->context_loss_count ||
!context_lost_cnt_after) {
omap_gpio_restore_context(bank);

Restoring context when the context_lost_cnt_after == 0 is clearly
wrong, since this will be true until the first off-mode transition
(which could be never, if off-mode is never enabled.)  This check
causes the context to be restored on *every* runtime PM transition.

Before commit 1b1287032 (gpio/omap: fix missing check in
*_runtime_suspend()), this code was never executed in non-OFF mode, so
there were never spurious context restores happening.  After that
change though, spurious context restores could happen.

To fix, simply remove the !context_lost_cnt_after check. It is not
needed.

This bug was found when noticing that the smc911x NIC on 3530/Overo
was not working, and git bisect tracked it down to this patch.  It
seems that the spurious context restore was causing the smsc911x to
not be properly probed on this platform.

Tested-by: Tony Lindgren <tony@atomide.com>
Acked-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
drivers/gpio/gpio-omap.c