[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190906190857.GA14545@roeck-us.net>
Date: Fri, 6 Sep 2019 12:08:57 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@...aro.org>,
agross@...nel.org, wim@...ux-watchdog.org,
linux-arm-msm@...r.kernel.org, linux-watchdog@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] watchdog: qcom: support pre-timeout when the bark irq
is available
On Fri, Sep 06, 2019 at 10:40:09AM -0700, Bjorn Andersson wrote:
> On Thu 05 Sep 14:00 PDT 2019, Jorge Ramirez-Ortiz wrote:
> > diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
> [..]
> > +static inline int qcom_get_enable(struct watchdog_device *wdd)
> > +{
> > + int enable = QCOM_WDT_ENABLE;
> > +
> > + if (wdd->info->options & WDIOF_PRETIMEOUT)
> > + enable |= QCOM_WDT_ENABLE_IRQ;
>
> Looking at downstream they conditionally write 3 to WDT_EN during
> initialization, but during suspend/resume they just set it to back to 1.
>
Looks like a bug to me.
Either case, per API, pretimeout is enabled with the value of pretimeout,
not with interrupt information from DT. I am not inclined to accept the
above condition for enabling it.
> So I don't think you should touch BIT(1) (which name doesn't match
> downstream or the register documentation)
>
You mean touching bit 1 is wrong to start with, and it is not a bit used
to enable the interrupt (and thus pretimeout) ?
Guess I'll need to dig out the manual myself.
Guenter
Powered by blists - more mailing lists