All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Prabhakar <prabhakar.csengg@gmail.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Magnus Damm <magnus.damm@gmail.com>,
	linux-rtc@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Fabrizio Castro <fabrizio.castro.jz@renesas.com>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 09/12] rtc: rzn1: Use temporary variable for struct device
Date: Wed, 17 Jun 2026 13:08:44 +0200	[thread overview]
Message-ID: <ajKAPJGrea01XVeI@shikoro> (raw)
In-Reply-To: <20260615154805.1619693-10-prabhakar.mahadev-lad.rj@bp.renesas.com>

[-- Attachment #1: Type: text/plain, Size: 3370 bytes --]

Hi,

Sashiko found issues, not introduced by your patch, but still. I
curated the list and left only those which I think are valid. Do you
have time to look at these issues?

Thank you and happy hacking,

   Wolfram

> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Asynchronous pm_runtime_put() is used instead of pm_runtime_put_sync() before runtime PM is disabled, potentially leaving the device powered on.
> - [High] If the optional 'xtal' clock is missing, readl_poll_timeout() loops forever with a 0 timeout, risking a boot hang.
> - [High] The driver's `remove` callback prematurely disables hardware interrupts and drops the runtime PM reference while the RTC device is still fully registered.
> --
> 
> commit b7f73c7d0932a6e78b12419c5912ad3243637b8f
> Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> rtc: rzn1: Use temporary variable for struct device
> 
> This patch simplifies the rzn1_rtc_probe function by using a local temporary
> variable for the struct device pointer. This avoids repeated dereferences of
> pdev->dev throughout the function.
> 
> > diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> > index bc6af59744e48..25cad9213147d 100644
> > --- a/drivers/rtc/rtc-rzn1.c
> > +++ b/drivers/rtc/rtc-rzn1.c
> [ ... ]
> >  	if (IS_ERR(xtal)) {
> >  		ret = PTR_ERR(xtal);
> >  		goto dis_runtime_pm;
> [ ... ]
> > @@ -486,18 +487,18 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
> [ ... ]
> >  	device_init_wakeup(dev, true);
> >  
> >  	ret = devm_rtc_register_device(rtc->rtcdev);
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but does registering the RTC
> device using devm_rtc_register_device() create a race condition during
> teardown?
> 
> In rzn1_rtc_remove(), the driver manually disables interrupts and calls
> pm_runtime_put() before devres has unregistered the RTC device:
> 
> 	writel(0, rtc->base + RZN1_RTC_CTL1);
> 	pm_runtime_put(&pdev->dev);
> 
> Could userspace still interact with the RTC during this window via ioctls
> or sysfs, potentially causing synchronous bus faults since the hardware is
> already suspended? Should teardown be bound using
> devm_add_action_or_reset() to guarantee correct reverse execution order?

[wsa] Or maybe not use devm then?

> 
> >  	if (ret)
> > @@ -506,7 +507,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
> >  	return 0;
> >  
> >  dis_runtime_pm:
> > -	pm_runtime_put(&pdev->dev);
> > +	pm_runtime_put(dev);
> 
> [Severity: High]
> This is a pre-existing issue, but does using pm_runtime_put() here (and in
> rzn1_rtc_remove) leave the device powered on indefinitely?
> 
> Since devm_pm_runtime_enable(dev) schedules pm_runtime_disable() to
> execute during devres cleanup, calling pm_runtime_put() only queues an
> asynchronous idle check. The immediate return triggers devres cleanup,
> which executes a barrier that explicitly cancels pending async operations.
> 
> Should this use pm_runtime_put_sync() instead to ensure the device is
> synchronously suspended before teardown?
> 
> >  	return ret;
> >  }
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=9

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2026-06-17 11:08 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-15 15:47 [PATCH 00/12] Add RTC support for Renesas RZ/T2H and RZ/N2H SoCs Prabhakar
2026-06-15 15:47 ` [PATCH 01/12] dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support Prabhakar
2026-06-15 15:56   ` sashiko-bot
2026-06-15 16:22   ` Conor Dooley
2026-06-17  9:38   ` Wolfram Sang
2026-06-15 15:47 ` [PATCH 02/12] rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt Prabhakar
2026-06-15 15:58   ` sashiko-bot
2026-06-17  9:55   ` Wolfram Sang
2026-06-15 15:47 ` [PATCH 03/12] rtc: rzn1: Fix malformed MODULE_AUTHOR string Prabhakar
2026-06-17  7:19   ` Geert Uytterhoeven
2026-06-17  9:55   ` Wolfram Sang
2026-06-15 15:47 ` [PATCH 04/12] rtc: Kconfig: Broaden RTC_DRV_RZN1 dependency to ARCH_RENESAS Prabhakar
2026-06-17  9:57   ` Wolfram Sang
2026-06-15 15:47 ` [PATCH 05/12] rtc: rzn1: Add system suspend/resume support and wakeup capability Prabhakar
2026-06-15 15:59   ` sashiko-bot
2026-06-17 10:02   ` Wolfram Sang
2026-06-15 15:47 ` [PATCH 06/12] rtc: rzn1: Sort headers alphabetically Prabhakar
2026-06-17  7:22   ` Geert Uytterhoeven
2026-06-17 10:04     ` Wolfram Sang
2026-06-15 15:48 ` [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems Prabhakar
2026-06-15 16:00   ` sashiko-bot
2026-06-17  7:29   ` Geert Uytterhoeven
2026-06-17 10:49   ` Wolfram Sang
2026-06-17 10:57   ` Wolfram Sang
2026-06-15 15:48 ` [PATCH 08/12] rtc: rzn1: Dynamically calculate synchronization delay based on clock rate Prabhakar
2026-06-15 15:57   ` sashiko-bot
2026-06-17 10:58   ` Wolfram Sang
2026-06-15 15:48 ` [PATCH 09/12] rtc: rzn1: Use temporary variable for struct device Prabhakar
2026-06-15 17:56   ` sashiko-bot
2026-06-17 11:00   ` Wolfram Sang
2026-06-17 11:08   ` Wolfram Sang [this message]
2026-06-15 15:48 ` [PATCH 10/12] rtc: rzn1: Consistently use dev_err_probe() Prabhakar
2026-06-17  7:24   ` Geert Uytterhoeven
2026-06-17 11:01   ` Wolfram Sang
2026-06-15 15:48 ` [PATCH 11/12] rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access Prabhakar
2026-06-15 15:57   ` sashiko-bot
2026-06-17 11:06   ` Wolfram Sang
2026-06-15 15:48 ` [PATCH 12/12] rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs Prabhakar
2026-06-15 15:58   ` sashiko-bot
2026-06-17 11:10   ` Wolfram Sang
2026-06-17  9:18 ` [PATCH 00/12] Add RTC " Wolfram Sang
2026-06-17 11:12   ` Wolfram Sang

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=ajKAPJGrea01XVeI@shikoro \
    --to=wsa+renesas@sang-engineering.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fabrizio.castro.jz@renesas.com \
    --cc=geert+renesas@glider.be \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=prabhakar.csengg@gmail.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=robh@kernel.org \
    /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.