devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Lakshay Piplani" <lakshay.piplani@nxp.com>
Cc: linux-rtc@vger.kernel.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v10 2/2] rtc: Add NXP PCF85053 driver support
Date: Mon, 14 Sep 2026 14:34:39 +0000	[thread overview]
Message-ID: <20260914143439.D15BA1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260914141537.3881890-2-lakshay.piplani@nxp.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Possible use-after-free of `rtc` object in `rtc->irqwork` due to unbalanced devres teardown order.
- [High] Missing mutual exclusion between the threaded IRQ handler and alarm configuration leads to dropped alarms.
--

commit 41cf346ef49a0ce7f8953c6b31dac43a5fae5017
Author: Lakshay Piplani <lakshay.piplani@nxp.com>
Subject: rtc: Add NXP PCF85053 driver support

This commit introduces support for the NXP PCF85053 I2C RTC. It includes
timer and calendar functionality, alarm management, and clock output control.

diff --git a/drivers/rtc/rtc-pcf85053.c b/drivers/rtc/rtc-pcf85053.c
--- a/drivers/rtc/rtc-pcf85053.c
+++ b/drivers/rtc/rtc-pcf85053.c

[ ... ]

> +static irqreturn_t pcf85053_irq(int irq, void *dev_id)
> +{
> +	struct device *dev = dev_id;
> +	struct pcf85053 *pcf85053 = dev_get_drvdata(dev);
> +	unsigned int st;
> +	int err;
> +
> +	err = regmap_read(pcf85053->regmap, PCF85053_REG_ST, &st);
> +	if (err || !(st & PCF85053_BIT_AF))
> +		return IRQ_NONE;
> +
> +	/*
> +	 * The alarm matches every day; disable AIE to make it one-shot. Mask
> +	 * the interrupt before clearing AF so there is no window where AF is
> +	 * cleared but AIE is still able to re-assert the line.
> +	 */
> +	err = pcf85053_set_aie(pcf85053->regmap, false);

[Severity: High]
Could this threaded IRQ handler race with pcf85053_rtc_set_alarm() and drop a
newly programmed alarm?

If the IRQ thread reads the status register and sees the alarm flag AF is
set, but is then preempted by a userspace process programming a new alarm via
pcf85053_rtc_set_alarm():

Userspace in pcf85053_rtc_set_alarm() would:
- configure the new time
- clear AF
- enable AIE

When the IRQ thread resumes here, it calls pcf85053_set_aie(..., false).
Would this overwrite the newly enabled AIE bit and silently disable the new
alarm interrupt?

[ ... ]

> +static int pcf85053_probe(struct i2c_client *client)
> +{
> +	const struct pcf85053_config *config;
> +	struct device *dev = &client->dev;
> +	const char *iface = NULL;
> +	struct pcf85053 *pcf85053;
> +	int err;

[ ... ]

> +	pcf85053->rtc = devm_rtc_allocate_device(dev);
> +	if (IS_ERR(pcf85053->rtc))
> +		return PTR_ERR(pcf85053->rtc);

[ ... ]

> +	if (config->has_alarms && pcf85053->is_primary && client->irq > 0) {
> +		/*
> +		 * ALRT is shared by the alarm (AIE), oscillator-fail (OFIE) and
> +		 * RTC-clear (CIE) sources. This driver only services the alarm,
> +		 * so disable the other two; otherwise ALRT could stay asserted
> +		 * with AF=0 and the handler could not clear it.
> +		 */
> +		err = regmap_update_bits(pcf85053->regmap, PCF85053_REG_CTRL,
> +					 PCF85053_BIT_OFIE | PCF85053_BIT_CIE, 0);
> +		if (err)
> +			return err;
> +
> +		err = devm_request_threaded_irq(dev, client->irq,
> +						NULL, pcf85053_irq,
> +						IRQF_ONESHOT,
> +						"pcf85053", dev);

[Severity: High]
Is there a potential use-after-free during device unbind due to the devres
allocation order here?

Since devres cleans up in reverse order of creation:
1. devm_rtc_register_device() unregisters the RTC.
2. devm_request_threaded_irq() frees the IRQ.
3. devm_rtc_allocate_device() frees the RTC structure.

If a hardware alarm interrupt fires exactly in the window after the RTC is
unregistered but before the IRQ is freed, the handler pcf85053_irq() will
execute and call rtc_update_irq().

This unconditionally queues rtc->irqwork, but the rtc object will be freed
momentarily when devm_rtc_allocate_device() unrolls. Can this result in a
use-after-free when the scheduled work runs on the freed rtc object?

> +		if (err)
> +			return dev_err_probe(dev, err,
> +					     "unable to request IRQ %d\n",
> +					     client->irq);
> +
> +		set_bit(RTC_FEATURE_ALARM, pcf85053->rtc->features);
> +		err = devm_device_init_wakeup(dev);
> +		if (err)
> +			return dev_err_probe(dev, err,
> +					     "failed to initialize wakeup\n");
> +		err = devm_pm_set_wake_irq(dev, client->irq);
> +		if (err)
> +			return dev_err_probe(dev, err,
> +					     "failed to set wake IRQ\n");
> +	}
> +
> +#ifdef CONFIG_COMMON_CLK
> +	err = pcf85053_clkout_register_clk(pcf85053);
> +	if (err)
> +		return err;
> +#endif
> +
> +	return devm_rtc_register_device(pcf85053->rtc);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914141537.3881890-1-lakshay.piplani@nxp.com?part=2

  reply	other threads:[~2026-09-14 14:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14 14:15 [PATCH v10 1/2] dt-bindings: rtc: Add pcf85053 support Lakshay Piplani
2026-09-14 14:15 ` [PATCH v10 2/2] rtc: Add NXP PCF85053 driver support Lakshay Piplani
2026-09-14 14:34   ` sashiko-bot [this message]
2026-09-14 14:51     ` [EXT] " Lakshay Piplani
2026-09-16  7:24       ` Sverdlin, Alexander
2026-09-18  5:27         ` Lakshay Piplani
2026-09-14 14:24 ` [PATCH v10 1/2] dt-bindings: rtc: Add pcf85053 support 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=20260914143439.D15BA1F000FF@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).