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