rtc: stmp3xxx: use devm_platform_ioremap_resource()
Subsystems (2)
PATCH 1/1 rtc: stmp3xxx: use devm_platform_ioremap_resource()
Replace the open-coded platform_get_resource() plus devm_ioremap() sequence with a single devm_platform_ioremap_resource() call, which folds the resource lookup and mapping into one step and returns an ERR_PTR on failure, checked with IS_ERR() and propagated via PTR_ERR().
Move the mapping ahead of the devm_kzalloc() so that an error or deferred probe is handled before the rtc_data allocation, avoiding needless work.
The fsl,stmp3xxx-rtc nodes in imx23.dtsi (reg = <0x8005c000 0x2000>) and imx28.dtsi (reg = <0x80056000 0x2000>) each provide a single non-overlapping IORESOURCE_MEM window, so the region reservation now performed by devm_platform_ioremap_resource() introduces no conflict.
Built for ARM (mxs_defconfig + CONFIG_RTC_DRV_STMP) with LLVM=1; drivers/rtc/rtc-stmp3xxx.o compiles cleanly.
--- drivers/rtc/rtc-stmp3xxx.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-)
drivers/rtc/rtc-stmp3xxx.c +6 -13
@@ -245,28 +245,21 @@ static void stmp3xxx_rtc_remove(struct platform_device *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 =0 ;int err; + io =devm_platform_ioremap_resource (pdev,0 ); +if (IS_ERR (io)) +return PTR_ERR (io); + rtc_data =devm_kzalloc (&pdev->dev,sizeof (*rtc_data),GFP_KERNEL );if (!rtc_data)return -ENOMEM ; - r =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); -if (!r) { -dev_err (&pdev->dev,"failed to get resource\n" ); -return -ENXIO ; - } - - rtc_data->io =devm_ioremap (&pdev->dev, r->start,resource_size (r)); -if (!rtc_data->io) { -dev_err (&pdev->dev,"ioremap failed\n" ); -return -EIO ; - } - + rtc_data->io = io; rtc_data->irq_alarm =platform_get_irq (pdev,0 ); rtc_stat =readl (rtc_data->io +STMP3XXX_RTC_STAT );
Signature · 1 line
2.55.0
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The return value of platform_get_irq() is not checked for errors, breaking deferred probing and unnecessarily disrupting hardware state.
- [High] The child watchdog platform device is never unregistered when the RTC driver is unbound, leading to a leaked device and potential Use-After-Free. --
--- Patch [1]: [PATCH] rtc: stmp3xxx: use devm_platform_ioremap_resource() --- commit eb7d944b8c0d01b4294ccf13b092d4f30d47bb4e
Author: Rosen Penev <[email protected]>
rtc: stmp3xxx: use devm_platform_ioremap_resource()
Replace the open-coded platform_get_resource() plus devm_ioremap() sequence with a single devm_platform_ioremap_resource() call, which folds the resource lookup and mapping into one step and returns an ERR_PTR on failure, checked with IS_ERR() and propagated via PTR_ERR().
drivers/rtc/rtc-stmp3xxx.c static void stmp3xxx_rtc_remove(struct platform_device *pdev)
Quoted 5 lines
drivers/rtc/rtc-stmp3xxx.c +0
-0@@ -245,28 +245,21 @@ static void stmp3xxx_rtc_remove(struct platform_device *pdev)
[Severity: High]
This is a pre-existing issue, but I noticed that stmp3xxx_rtc_remove() doesn't unregister the dynamically added child platform device created by stmp3xxx_wdt_register() during probe.
If the RTC driver is unbound, the child watchdog device remains registered. A subsequent watchdog operation like stmp3xxx_wdt_set_timeout() will call dev_get_drvdata(dev->parent), which returns NULL because the parent's drvdata is cleared during unbind. This leads to a NULL pointer dereference when accessing rtc_data->io.
Could this be fixed by saving the child device pointer and unregistering it in the remove function?
Quoted 3 lines
drivers/rtc/rtc-stmp3xxx.c +0
-0static int stmp3xxx_rtc_probe (struct platform_device *pdev) {struct stmp3xxx_rtc_data *rtc_data;
[ ... ]
drivers/rtc/rtc-stmp3xxx.c static void stmp3xxx_rtc_remove(struct platform_device *pdev) · line 263
Quoted 8 lines
drivers/rtc/rtc-stmp3xxx.c +1
-6- rtc_data->io =devm_ioremap (&pdev->dev, r->start,resource_size (r)); -if (!rtc_data->io) { -dev_err (&pdev->dev,"ioremap failed\n" ); -return -EIO ; - } - + rtc_data->io = io; rtc_data->irq_alarm =platform_get_irq (pdev,0 );
[Severity: High]
This isn't a bug introduced by this patch, but does this lack of error checking break deferred probing?
If platform_get_irq() returns -EPROBE_DEFER, it is assigned directly to rtc_data->irq_alarm. Later, this negative error code is passed to devm_request_irq() in stmp3xxx_rtc_probe():
err = devm_request_irq(&pdev->dev, rtc_data->irq_alarm,
stmp3xxx_rtc_interrupt, 0, "RTC alarm", &pdev->dev);Since devm_request_irq() expects an unsigned int for the IRQ number, the negative value is cast and fails with -EINVAL. The driver then returns -EINVAL instead of -EPROBE_DEFER, which permanently prevents the RTC and watchdog from probing on systems that require deferred probing for the interrupt controller.
Should we add a check for negative error codes from platform_get_irq() here?
Quoted 2 lines
rtc_stat=readl(rtc_data->io + STMP3XXX_RTC_STAT);
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1