Re: [PATCHv2] rtc: stmp3xxx: use devm_platform_ioremap_resource()

Thank you for your contribution! Sashiko AI review found 3 potential issue(=
s) to consider:

New issues:
- [Low] The local variable `irq_alarm` is used in `stmp3xxx_rtc_probe()` wi=
thout being declared.

Pre-existing issues:
- [High] The dynamically registered child watchdog device is not unregister=
ed when the RTC driver is unbound, leading to a NULL pointer dereference.
- [High] Incorrect devm cleanup order creates a race condition where a pend=
ing interrupt can trigger a Use-After-Free by re-queueing an already-cancel=
ed work object.
--

--- Patch [1]: [PATCHv2] rtc: stmp3xxx: use devm_platform_ioremap_resource(=
) ---
commit 9966c4bcfecfb31f7bf74af8e9b176bb32e74820
Author: Rosen Penev <[email protected]>

rtc: stmp3xxx: use devm_platform_ioremap_resource()

This patch refactors the driver to use devm_platform_ioremap_resource()
instead of open-coding the resource lookup and mapping. It moves the
mapping ahead of the data allocation to handle deferred probes earlier.
It also removes irq_alarm from the private struct and adds an error
check for platform_get_irq().

> diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c
> index 7afcd14aeee56..e789458ba96a6 100644
> --- a/drivers/rtc/rtc-stmp3xxx.c
> +++ b/drivers/rtc/rtc-stmp3xxx.c
> @@ -245,29 +244,25 @@ static void stmp3xxx_rtc_remove(struct platform_dev=
ice *pdev)
>  static int stmp3xxx_rtc_probe(struct platform_device *pdev)
>  {
>  	struct stmp3xxx_rtc_data *rtc_data;
> -	struct resource *r;
> +	void __iomem *io;
>  	u32 rtc_stat;
>  	u32 pers0_set, pers0_clr;
>  	u32 crystalfreq =3D 0;
>  	int err;
> =20
> +	irq_alarm =3D platform_get_irq(pdev, 0);

[Severity: Low]
Does this regression introduce a build failure?

The variable irq_alarm was removed from the private struct stmp3xxx_rtc_dat=
a,
but it is used here without being declared as a local int variable first.

> +	if (irq_alarm < 0)
> +		return irq_alarm;
> +
> +	io =3D devm_platform_ioremap_resource(pdev, 0);

[ ... ]

> @@ -354,13 +349,10 @@ static int stmp3xxx_rtc_probe(struct platform_devic=
e *pdev)
>  	if (IS_ERR(rtc_data->rtc))
>  		return PTR_ERR(rtc_data->rtc);
> =20
> -	err =3D devm_request_irq(&pdev->dev, rtc_data->irq_alarm,
> +	err =3D devm_request_irq(&pdev->dev, irq_alarm,
>  			stmp3xxx_rtc_interrupt, 0, "RTC alarm", &pdev->dev);

[Severity: High]
This isn't a bug introduced by this patch, but does this devm initialization
order create a use-after-free race condition during driver unbind?

The IRQ is requested via devm_request_irq() before the RTC device is
registered via devm_rtc_register_device() further down in probe.

During driver removal, devres cleans up in reverse order: the RTC device is
unregistered first (which cancels the irqwork), and the IRQ is freed second.

If a pending hardware interrupt fires in the window between these two steps,
could stmp3xxx_rtc_interrupt() unconditionally call rtc_update_irq(), which
re-queues the irqwork on an RTC device that is about to be freed?

> -	if (err) {
> -		dev_err(&pdev->dev, "Cannot claim IRQ%d\n",
> -			rtc_data->irq_alarm);
> +	if (err)
>  		return err;
> -	}
> =20
>  	rtc_data->rtc->ops =3D &stmp3xxx_rtc_ops;
>  	rtc_data->rtc->range_max =3D U32_MAX;

[Severity: High]
This is a pre-existing issue, but does the dynamically registered watchdog
device leak on driver unbind?

Looking at stmp3xxx_wdt_register() called at the end of stmp3xxx_rtc_probe(=
),
the watchdog child device is manually added with platform_device_add(), but
stmp3xxx_rtc_remove() doesn't appear to call platform_device_unregister()
to clean this up.

If the RTC driver is unbound via sysfs, the parent device's drvdata is
cleared and devm resources are freed. Because the child watchdog device
remains active, could a subsequent access via stmp3xxx_wdt_set_timeout()
dereference the now-NULL parent drvdata and crash the system?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260728005303.5749=
[email protected]?part=3D1