From: sashiko-bot@kernel.org
To: "Lakshay Piplani" <lakshay.piplani@nxp.com>
Cc: linux-rtc@vger.kernel.org, devicetree@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org,
linux-watchdog@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>
Subject: Re: [RESEND v4 2/5] rtc: pcf85363: support reporting battery switch-over via RTC_VL
Date: Wed, 12 Aug 2026 07:55:10 +0000 [thread overview]
Message-ID: <20260812075511.42F541F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812074533.3545058-2-lakshay.piplani@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The IRQ handler silently clears the Battery Switch-over Flag (BSF) from the hardware register without saving its state, causing battery switch-over events to be lost if an interrupt triggers before userspace calls RTC_VL_READ.
Pre-existing issues:
- [High] `pcf85363_probe()` unconditionally wipes the `CTRL_FLAGS` register, destroying boot-time battery switch-over events before they can be read via `RTC_VL_READ`.
--
--- Patch [2]: [RESEND v4 2/5] rtc: pcf85363: support reporting battery switch-over via RTC_VL ---
commit 641bd03440f1f0094b5ca119b02a17fb2dd848b5
Author: Lakshay Piplani <lakshay.piplani@nxp.com>
rtc: pcf85363: support reporting battery switch-over via RTC_VL
Add battery switch-over reporting for PCF85263/PCF85363 using the standard
RTC_VL_* ioctl interface. When the backup supply takes over, the BSF flag
is exposed to userspace through RTC_VL_READ and can be cleared using
RTC_VL_CLR.
> diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
> index 540042b9eec8f..c03d5a65c5f79 100644
> --- a/drivers/rtc/rtc-pcf85363.c
> +++ b/drivers/rtc/rtc-pcf85363.c
[ ... ]
> @@ -295,23 +296,67 @@ static int pcf85363_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
> static irqreturn_t pcf85363_rtc_handle_irq(int irq, void *dev_id)
> {
> struct pcf85363 *pcf85363 = i2c_get_clientdata(dev_id);
> + bool handled = false;
> unsigned int flags;
> int err;
>
> err = regmap_read(pcf85363->regmap, CTRL_FLAGS, &flags);
> +
> if (err)
> return IRQ_NONE;
>
> + if (flags) {
> + dev_dbg(&pcf85363->rtc->dev, "IRQ flags: 0x%02x%s%s\n",
> + flags, (flags & FLAGS_A1F) ? " [A1F]" : "",
> + (flags & FLAGS_BSF) ? " [BSF]" : "");
> + }
> +
> if (flags & FLAGS_A1F) {
> rtc_update_irq(pcf85363->rtc, 1, RTC_IRQF | RTC_AF);
> regmap_update_bits(pcf85363->regmap, CTRL_FLAGS, FLAGS_A1F, 0);
> - return IRQ_HANDLED;
> + handled = true;
> }
>
> - return IRQ_NONE;
> + if (flags & FLAGS_BSF) {
> + regmap_update_bits(pcf85363->regmap, CTRL_FLAGS, FLAGS_BSF, 0);
> + handled = true;
> + }
[Severity: Medium]
Does this unconditionally clear the hardware Battery Switch-over Flag (BSF)
without saving its state?
If an interrupt triggers before userspace calls RTC_VL_READ, won't the
battery switch-over event be lost since the hardware flag is cleared but not
cached in software?
> +
> + return handled ? IRQ_HANDLED : IRQ_NONE;
> +}
> +
> +static int pcf85363_rtc_ioctl(struct device *dev,
> + unsigned int cmd, unsigned long arg)
> +{
> + struct pcf85363 *pcf85363 = dev_get_drvdata(dev);
> + unsigned int val;
> + int ret;
> +
> + switch (cmd) {
> + case RTC_VL_READ: {
> + u32 status = 0;
> +
> + ret = regmap_read(pcf85363->regmap, CTRL_FLAGS, &val);
[Severity: Medium]
Because RTC_VL_READ reads directly from the hardware register, it will return
0 if the IRQ handler has already cleared the flag.
> +
> + if (ret)
> + return ret;
> +
> + if (val & FLAGS_BSF)
> + status |= RTC_VL_BACKUP_SWITCH;
> +
> + return put_user(status, (u32 __user *)arg);
> + }
> +
> + case RTC_VL_CLR:
> + return regmap_update_bits(pcf85363->regmap, CTRL_FLAGS, FLAGS_BSF, 0);
> +
> + default:
> + return -ENOIOCTLCMD;
> + }
> }
[Severity: High]
This isn't a bug introduced by this patch, but the pre-existing code
in pcf85363_probe() appears to break the boot-time power loss detection
intended by this new feature.
During system boot, pcf85363_probe() unconditionally clears all hardware flags
if an IRQ or wakeup source is configured:
drivers/rtc/rtc-pcf85363.c:pcf85363_probe() {
...
if (client->irq > 0 || wakeup_source) {
regmap_write(pcf85363->regmap, CTRL_FLAGS, 0);
regmap_update_bits(pcf85363->regmap, CTRL_PIN_IO,
PIN_IO_INTAPM, PIN_IO_INTA_OUT);
}
...
}
Does this destroy the battery switch-over event before userspace can query it
with RTC_VL_READ?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260812074533.3545058-1-lakshay.piplani@nxp.com?part=2
next prev parent reply other threads:[~2026-08-12 7:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 7:45 [RESEND v4 1/5] dt-bindings: rtc: nxp,pcf85363: add timestamp mode config Lakshay Piplani
2026-08-12 7:45 ` [RESEND v4 2/5] rtc: pcf85363: support reporting battery switch-over via RTC_VL Lakshay Piplani
2026-08-12 7:55 ` sashiko-bot [this message]
2026-08-12 7:45 ` [RESEND v4 3/5] rtc: pcf85363: add timestamp support with configurable timestamp mode Lakshay Piplani
2026-08-12 7:58 ` sashiko-bot
2026-08-12 7:45 ` [RESEND v4 4/5] rtc: pcf85363: add oscillator offset calibration support Lakshay Piplani
2026-08-12 8:00 ` sashiko-bot
2026-08-12 7:45 ` [RESEND v4 5/5] rtc: pcf85363: add watchdog support with configurable step size Lakshay Piplani
2026-08-12 7:57 ` sashiko-bot
2026-08-12 7:49 ` [RESEND v4 1/5] dt-bindings: rtc: nxp,pcf85363: add timestamp mode config sashiko-bot
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=20260812075511.42F541F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lakshay.piplani@nxp.com \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=robh@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 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.