In the absence of a physical reset line the chip is reset by writing the first register, which is done after the register patch has been applied. This patch synchronises the register cache after the reset to preserve any register changes that had been applied.
Signed-off-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com> Reviewed-by: Mark Brown <broo...@opensource.wolfsonmicro.com> --- Apologies but it seems I accidentally generated yesterdays patch against a local development branch rather than the upstream branch. Sorry for the inconvience here is a fixed version. drivers/mfd/arizona-core.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c index 202bf55..f4f9bf8 100644 --- a/drivers/mfd/arizona-core.c +++ b/drivers/mfd/arizona-core.c @@ -415,11 +415,19 @@ int __devinit arizona_dev_init(struct arizona *arizona) /* If we have a /RESET GPIO we'll already be reset */ if (!arizona->pdata.reset) { + regcache_mark_dirty(arizona->regmap); + ret = regmap_write(arizona->regmap, ARIZONA_SOFTWARE_RESET, 0); if (ret != 0) { dev_err(dev, "Failed to reset device: %d\n", ret); goto err_reset; } + + ret = regcache_sync(arizona->regmap); + if (ret != 0) { + dev_err(dev, "Failed to sync device: %d\n", ret); + goto err_reset; + } } ret = arizona_wait_for_boot(arizona); -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/