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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).