Linux RTC
 help / color / mirror / Atom feed
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

      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