All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: "Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>
Cc: Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Wim Van Sebroeck <wim@linux-watchdog.org>,
	linux-watchdog@vger.kernel.org,
	Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] watchdog: qcom: Remove incorrect usage of QCOM_WDT_ENABLE_IRQ
Date: Mon, 01 Feb 2021 11:23:45 +0530	[thread overview]
Message-ID: <7e30acdb750c44d30d5903e0d2afa641@codeaurora.org> (raw)

On 2021-01-31 22:33, Jorge Ramirez-Ortiz, Foundries wrote:
> On 28/01/21, Sai Prakash Ranjan wrote:
>> On 2021-01-28 13:49, Jorge Ramirez-Ortiz, Foundries wrote:
>> > On 26/01/21, Sai Prakash Ranjan wrote:
>> > > As per register documentation, QCOM_WDT_ENABLE_IRQ which is BIT(1)
>> > > of watchdog control register is wakeup interrupt enable bit and
>> > > not related to bark interrupt at all, BIT(0) is used for that.
>> > > So remove incorrect usage of this bit when supporting bark irq for
>> > > pre-timeout notification. Currently with this bit set and bark
>> > > interrupt specified, pre-timeout notification and/or watchdog
>> > > reset/bite does not occur.
>> > >
>> > > Fixes: 36375491a439 ("watchdog: qcom: support pre-timeout when the
>> > > bark irq is available")
>> > > Cc: stable@vger.kernel.org
>> > > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> > > ---
>> > >
>> > > Reading the conversations from when qcom pre-timeout support was
>> > > added [1], Bjorn already had mentioned it was not right to touch this
>> > > bit, not sure which SoC the pre-timeout was tested on at that time,
>> > > but I have tested this on SDM845, SM8150, SC7180 and watchdog bark
>> > > and bite does not occur with enabling this bit with the bark irq
>> > > specified in DT.
>> >
>> > this was tested on QCS404. have you validated there? unfortunately I
>> > no longer have access to that hardware or the documentation
>> >
>> 
>> I didn't validate on qcs404 yet since I didn't have access to it.
>> But now that you mention it, let me arrange for a setup and test it
>> there as well. Note: I did not see bark irq entry in upstream qcs404
>> dtsi, so you must have had some local change when you tested?
> 
> TBH I dont quite remember. I suppose that if those with access to the
> documents and hardware are OK with this change then it shouldnt cause
> regressions (I just cant check from my end)
> 

No worries, I got the documentation access now and it is the same as
other SoCs which I have tested above, meaning the BIT(1) is not related
to bark irq. I am arranging a setup as well now, it took some time as
I don't work on QCS* chipsets but I can confirm by this week.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

             reply	other threads:[~2021-02-01  5:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01  5:53 Sai Prakash Ranjan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-01-26 15:02 [PATCH] watchdog: qcom: Remove incorrect usage of QCOM_WDT_ENABLE_IRQ Sai Prakash Ranjan
2021-01-26 15:23 ` Guenter Roeck
2021-01-26 15:23   ` Guenter Roeck
2021-01-26 15:53   ` Sai Prakash Ranjan
2021-01-28  1:33 ` Stephen Boyd
2021-01-28  1:33   ` Stephen Boyd
2021-01-28 11:03   ` Sai Prakash Ranjan
2021-01-28  8:19 ` Jorge Ramirez-Ortiz, Foundries
2021-01-28  8:19   ` Jorge Ramirez-Ortiz, Foundries
2021-01-28 11:08   ` Sai Prakash Ranjan
2021-01-31 17:03     ` Jorge Ramirez-Ortiz, Foundries
2021-03-01 19:59 ` patchwork-bot+linux-arm-msm

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=7e30acdb750c44d30d5903e0d2afa641@codeaurora.org \
    --to=saiprakash.ranjan@codeaurora.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=jorge.ramirez-ortiz@linaro.org \
    --cc=jorge@foundries.io \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=stable@vger.kernel.org \
    --cc=wim@linux-watchdog.org \
    /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.