From: Lee Jones <lee.jones@linaro.org>
To: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: LINUXKERNEL <linux-kernel@vger.kernel.org>,
Support Opensource <support.opensource@diasemi.com>
Subject: Re: [PATCH V1] mfd: da9053: ensure the FAULT_LOG is cleared during MFD driver probe
Date: Wed, 31 Aug 2016 09:52:31 +0100 [thread overview]
Message-ID: <20160831085231.GB27357@dell> (raw)
In-Reply-To: <20160706152448.445333FAC2@swsrvapps-01.diasemi.com>
On Wed, 06 Jul 2016, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> The function da9052_clear_fault_log() is added to mitigate the case of
> persistent data being transferred between reboots.
>
> Clearance of any the persistent information within the DA9053 FAULT_LOG
> register must be completed during start-up so the fault-log does not
> continue with previous values. A clearance function has been added here in
> the kernel driver because wiping the fault-log cannot be counted on outside
> the Linux kernel.
>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> Reviewed-by: Adam Thomson <adam.thomson.opensource@diasemi.com>
Applied, thanks.
> ---
> This patch applies against linux-next and v4.7-rc6
>
>
> Hi Lee,
>
> This patch is similar to the requirements for DA9062 and DA9063: to ensure
> the FAULT_LOG is started from a 'clean' position.
>
> The Dialog datasheet for DA9053 suggests: "The FAULT_LOG register has to
> be cleared from the host after reading, by writing a value of 11111111".
>
> See reference:
> commit 9011e4a8a6fe57f76511609930ed00d305389089
> Author: Steve Twiss <stwiss.opensource@diasemi.com>
> Date: Tue May 19 11:32:45 2015 +0100
>
> Regards,
> Steve
>
>
> drivers/mfd/da9052-core.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> index c0bf68a..a88c206 100644
> --- a/drivers/mfd/da9052-core.c
> +++ b/drivers/mfd/da9052-core.c
> @@ -167,6 +167,7 @@ static bool da9052_reg_writeable(struct device *dev, unsigned int reg)
> case DA9052_EVENT_B_REG:
> case DA9052_EVENT_C_REG:
> case DA9052_EVENT_D_REG:
> + case DA9052_FAULTLOG_REG:
> case DA9052_IRQ_MASK_A_REG:
> case DA9052_IRQ_MASK_B_REG:
> case DA9052_IRQ_MASK_C_REG:
> @@ -541,6 +542,52 @@ const struct regmap_config da9052_regmap_config = {
> };
> EXPORT_SYMBOL_GPL(da9052_regmap_config);
>
> +static int da9052_clear_fault_log(struct da9052 *da9052)
> +{
> + int ret = 0;
> + int fault_log = 0;
> +
> + fault_log = da9052_reg_read(da9052, DA9052_FAULTLOG_REG);
> + if (fault_log < 0) {
> + dev_err(da9052->dev,
> + "Cannot read FAULT_LOG %d\n", fault_log);
> + return fault_log;
> + }
> +
> + if (fault_log) {
> + if (fault_log & DA9052_FAULTLOG_TWDERROR)
> + dev_dbg(da9052->dev,
> + "Fault log entry detected: TWD_ERROR\n");
> + if (fault_log & DA9052_FAULTLOG_VDDFAULT)
> + dev_dbg(da9052->dev,
> + "Fault log entry detected: VDD_FAULT\n");
> + if (fault_log & DA9052_FAULTLOG_VDDSTART)
> + dev_dbg(da9052->dev,
> + "Fault log entry detected: VDD_START\n");
> + if (fault_log & DA9052_FAULTLOG_TEMPOVER)
> + dev_dbg(da9052->dev,
> + "Fault log entry detected: TEMP_OVER\n");
> + if (fault_log & DA9052_FAULTLOG_KEYSHUT)
> + dev_dbg(da9052->dev,
> + "Fault log entry detected: KEY_SHUT\n");
> + if (fault_log & DA9052_FAULTLOG_NSDSET)
> + dev_dbg(da9052->dev,
> + "Fault log entry detected: nSD_SHUT\n");
> + if (fault_log & DA9052_FAULTLOG_WAITSET)
> + dev_dbg(da9052->dev,
> + "Fault log entry detected: WAIT_SHUT\n");
> +
> + ret = da9052_reg_write(da9052,
> + DA9052_FAULTLOG_REG,
> + 0xFF);
> + if (ret < 0)
> + dev_err(da9052->dev,
> + "Cannot reset FAULT_LOG values %d\n", ret);
> + }
> +
> + return ret;
> +}
> +
> int da9052_device_init(struct da9052 *da9052, u8 chip_id)
> {
> struct da9052_pdata *pdata = dev_get_platdata(da9052->dev);
> @@ -549,6 +596,10 @@ int da9052_device_init(struct da9052 *da9052, u8 chip_id)
> mutex_init(&da9052->auxadc_lock);
> init_completion(&da9052->done);
>
> + ret = da9052_clear_fault_log(da9052);
> + if (ret < 0)
> + dev_warn(da9052->dev, "Cannot clear FAULT_LOG\n");
> +
> if (pdata && pdata->init != NULL)
> pdata->init(da9052);
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
prev parent reply other threads:[~2016-08-31 8:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 15:12 [PATCH V1] mfd: da9053: ensure the FAULT_LOG is cleared during MFD driver probe Steve Twiss
2016-08-05 9:05 ` Lee Jones
2016-08-08 11:05 ` Steve Twiss
2016-08-10 11:02 ` Steve Twiss
2016-08-15 12:37 ` Steve Twiss
2016-08-15 13:37 ` Lee Jones
2016-08-31 8:52 ` Lee Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160831085231.GB27357@dell \
--to=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stwiss.opensource@diasemi.com \
--cc=support.opensource@diasemi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.