[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <efab844a-4ffe-bc68-d99e-8688ad222e3a@quicinc.com>
Date: Mon, 6 Feb 2023 19:12:43 -0800
From: David Collins <quic_collinsd@...cinc.com>
To: Johan Hovold <johan+linaro@...nel.org>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Bjorn Andersson <andersson@...nel.org>
CC: Andy Gross <agross@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Alessandro Zummo <a.zummo@...ertech.it>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Maximilian Luz <luzmaximilian@...il.com>,
<linux-arm-msm@...r.kernel.org>, <linux-rtc@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<stable@...r.kernel.org>
Subject: Re: [PATCH v2 01/22] rtc: pm8xxx: fix set-alarm race
On 2/2/23 07:54, Johan Hovold wrote:
> Make sure to disable the alarm before updating the four alarm time
> registers to avoid spurious alarms during the update.
What scenario can encounter a spurious alarm triggering upon writing the
new alarm time inside of pm8xxx_rtc_set_alarm()?
> Note that the disable needs to be done outside of the ctrl_reg_lock
> section to prevent a racing alarm interrupt from disabling the newly set
> alarm when the lock is released.
What scenario shows the IRQ race issue that you mentioned? How does not
protecting this register write with a lock avoid the race condition?
> Fixes: 9a9a54ad7aa2 ("drivers/rtc: add support for Qualcomm PMIC8xxx RTC")
> Cc: stable@...r.kernel.org # 3.1
> Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> ---
> drivers/rtc/rtc-pm8xxx.c | 24 ++++++++++--------------
> 1 file changed, 10 insertions(+), 14 deletions(-)
Note that since locking is removed later in the patch series, my
questions above are mainly for the sake of curiosity.
Reviewed-by: David Collins <quic_collinsd@...cinc.com>
Thanks,
David
Powered by blists - more mailing lists