From: sashiko-bot@kernel.org
To: "A. Sverdlin" <alexander.sverdlin@siemens.com>
Cc: linux-rtc@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>
Subject: Re: [PATCH v3 4/4] rtc: pcf85063: add 1 Hz update interrupt (UIE) support
Date: Fri, 28 Aug 2026 17:00:40 +0000 [thread overview]
Message-ID: <20260828170040.E2B111F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260828164445.3907839-5-alexander.sverdlin@siemens.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] The driver completely ignores the requested alarm enable parameters, breaking generic `alarmtimers` (POSIX timers) and system wakeups.
Pre-existing issues:
- [High] In `pcf85063_rtc_alarm_irq_enable()`, the `PCF85063_CTRL2_AF` (Alarm Flag) bit is omitted from the `regmap_update_bits` mask and value, which can inadvertently clear a pending alarm interrupt.
--
commit 72f77be444d700f19ce672423be21e8db8ec0a3d
Author: Alexander Sverdlin <alexander.sverdlin@siemens.com>
rtc: pcf85063: add 1 Hz update interrupt (UIE) support
The PCF85063A/RV8263 have no dedicated 1 Hz update interrupt, but their
countdown timer can be sourced from a 1 Hz clock (TCF = 1 Hz, T = 1) to
generate a periodic interrupt on the INT pin. Use it to offload UIE to
the hardware, following the pattern of other RTC drivers.
> diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
> index a3af86456ccfc..32952e73f2f1c 100644
> --- a/drivers/rtc/rtc-pcf85063.c
> +++ b/drivers/rtc/rtc-pcf85063.c
[ ... ]
> @@ -211,23 +275,33 @@ static int pcf85063_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
> return ret;
>
> return regmap_update_bits(pcf85063->regmap, PCF85063_REG_CTRL2,
> - PCF85063_CTRL2_AIE | PCF85063_CTRL2_AF,
> - alrm->enabled ? PCF85063_CTRL2_AIE | PCF85063_CTRL2_AF : PCF85063_CTRL2_AF);
> + PCF85063_CTRL2_AIE | PCF85063_CTRL2_AF | PCF85063_CTRL2_TF,
> + pcf85063->rtc->aie_timer.enabled ?
> + PCF85063_CTRL2_AIE | PCF85063_CTRL2_AF | PCF85063_CTRL2_TF :
> + PCF85063_CTRL2_AF | PCF85063_CTRL2_TF);
> }
[Severity: High]
Does this code ignore the requested alrm->enabled parameter in favor of
pcf85063->rtc->aie_timer.enabled?
The RTC core multiplexes various timers onto the hardware alarm and passes the
desired hardware state via alrm->enabled here and via the enabled parameter in
pcf85063_rtc_alarm_irq_enable().
By checking aie_timer.enabled instead, it appears the driver will only enable
the hardware alarm for the legacy ioctl alarm. If a generic alarmtimer (such
as a system wakealarm or a POSIX timer) reaches the front of the queue, won't
aie_timer.enabled be false, silencing the requested alarm?
> static int pcf85063_rtc_alarm_irq_enable(struct device *dev,
> unsigned int enabled)
> {
> struct pcf85063 *pcf85063 = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = pcf85063_set_timer_1hz(pcf85063, pcf85063->rtc->uie_rtctimer.enabled);
> + if (ret)
> + return ret;
>
> return regmap_update_bits(pcf85063->regmap, PCF85063_REG_CTRL2,
> - PCF85063_CTRL2_AIE,
> - enabled ? PCF85063_CTRL2_AIE : 0);
> + PCF85063_CTRL2_AIE | PCF85063_CTRL2_TF,
> + pcf85063->rtc->aie_timer.enabled ?
> + PCF85063_CTRL2_AIE | PCF85063_CTRL2_TF : PCF85063_CTRL2_TF);
> }
[Severity: High]
This is a pre-existing issue, but does this read-modify-write omit
PCF85063_CTRL2_AF from the mask, potentially clearing a pending alarm?
Since the AF bit in PCF85063_REG_CTRL2 is write-0-to-clear, if the hardware
asserts the AF interrupt between the internal register read and write of this
operation, the read value will have AF=0. Because AF is not masked,
regmap_update_bits() will write back AF=0, which unintentionally clears the
newly asserted alarm flag.
Also, similar to pcf85063_rtc_set_alarm() above, does this code
inappropriately ignore the enabled parameter passed by the core?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260828164445.3907839-1-alexander.sverdlin@siemens.com?part=4
prev parent reply other threads:[~2026-08-28 17:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 16:44 [PATCH v3 0/4] rtc: pcf85063: Update interrupt support A. Sverdlin
2026-08-28 16:44 ` [PATCH v3 1/4] rtc: pcf85063: use devm_of_clk_add_hw_provider() for clkout A. Sverdlin
2026-08-28 16:51 ` sashiko-bot
2026-08-28 16:44 ` [PATCH v3 2/4] rtc: pcf85063: do not clear AIE in the interrupt handler A. Sverdlin
2026-08-28 17:05 ` sashiko-bot
2026-08-28 16:44 ` [PATCH v3 3/4] rtc: pcf85063: preserve the alarm flag in clkout register updates A. Sverdlin
2026-08-28 16:58 ` sashiko-bot
2026-08-28 17:21 ` Sverdlin, Alexander
2026-08-28 16:44 ` [PATCH v3 4/4] rtc: pcf85063: add 1 Hz update interrupt (UIE) support A. Sverdlin
2026-08-28 17:00 ` sashiko-bot [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=20260828170040.E2B111F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alexander.sverdlin@siemens.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-rtc@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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