All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Cc: imx@lists.linux.dev, Frank.Li@kernel.org, lee@kernel.org,
	mfd@lists.linux.dev
Subject: Re: [PATCH 5/8] pmdomain: imx: use platform_device_set_fwnode()
Date: Tue, 21 Jul 2026 09:26:05 +0000	[thread overview]
Message-ID: <20260721092605.DCBFA1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-5-2dee93f42c54@oss.qualcomm.com>

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

Pre-existing issues:
- [High] Pre-existing leak of dynamically added child `platform_device`s on probe error or unbind, leading to use-after-free of parent's devm-managed resources.
--

--- Patch [5]: [PATCH 5/8] pmdomain: imx: use platform_device_set_fwnode() ---
commit 4ab43e8055c75d8cfe06f1c383c67f571e59d263
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

pmdomain: imx: use platform_device_set_fwnode()

This commit updates the driver to prefer the higher-level
platform_device_set_fwnode() over the OF-specific
platform_device_set_of_node() for dynamically allocated platform devices.

> diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c
> --- a/drivers/pmdomain/imx/gpc.c
> +++ b/drivers/pmdomain/imx/gpc.c
> @@ -487,7 +487,7 @@ static int imx_gpc_probe(struct platform_device *pdev)
>  			domain->ipg_rate_mhz = ipg_rate_mhz;
>  
>  			pd_pdev->dev.parent = &pdev->dev;
> -			platform_device_set_of_node(pd_pdev, np);
> +			platform_device_set_fwnode(pd_pdev, of_fwnode_handle(np));
>  
>  			ret = platform_device_add(pd_pdev);
>  			if (ret) {
>  				platform_device_put(pd_pdev);
>  				return ret;
>  			}

[Severity: High]
This isn't a bug introduced by this patch, but does this error path leave
previously added child platform devices registered?

In imx_gpc_probe(), the child imx-pgc-power-domain platform devices are
added in a loop. If a subsequent iteration fails and returns here, it
triggers devres cleanup for the parent device, freeing resources like
the devm-managed regmap.

Because the previously added child devices are not unregistered on this
error path, will they remain bound with a dangling domain->regmap pointer?

Additionally, looking at imx_gpc_remove(), it entirely omits child
unregistration when the new DT binding is used, leaving the child
devices registered while parent devm resources are torn down:

drivers/pmdomain/imx/gpc.c:imx_gpc_remove() {
    ...
		}
	}

	of_node_put(pgc_node);
}

Could this also lead to a similar use-after-free of the regmap struct
on an explicit sysfs unbind?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com?part=5

  parent reply	other threads:[~2026-07-21  9:26 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20  9:24 [PATCH 0/8] driver core: prefer platform_device_set_fwnode() Bartosz Golaszewski
2026-07-20  9:24 ` [PATCH 1/8] powerpc/powermac: use platform_device_set_fwnode() Bartosz Golaszewski
2026-07-21  9:25   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 2/8] i2c: pxa-pci: " Bartosz Golaszewski
2026-07-20  9:41   ` Wolfram Sang
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 3/8] iommu/fsl: " Bartosz Golaszewski
2026-07-20 12:58   ` Robin Murphy
2026-07-20 13:39     ` Bartosz Golaszewski
2026-07-20 14:34       ` Robin Murphy
2026-07-20 14:34   ` Frank Li
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 4/8] net: bcmgenet: " Bartosz Golaszewski
2026-07-20 14:38   ` Andrew Lunn
2026-07-20 16:57     ` Florian Fainelli
2026-07-20 16:57       ` Florian Fainelli
2026-07-20 16:57       ` Florian Fainelli
2026-07-20 16:57       ` Florian Fainelli
2026-07-20 16:57       ` Florian Fainelli
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 5/8] pmdomain: imx: " Bartosz Golaszewski
2026-07-20 14:34   ` Frank Li
2026-07-21  9:26   ` sashiko-bot [this message]
2026-07-20  9:24 ` [PATCH 6/8] mfd: tps6586: " Bartosz Golaszewski
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 7/8] net: mv643xx: " Bartosz Golaszewski
2026-07-20 14:43   ` Andrew Lunn
2026-07-20 16:01     ` Bartosz Golaszewski
2026-07-20 18:28       ` Andrew Lunn
2026-07-21  7:57         ` Bartosz Golaszewski
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 8/8] slimbus: qcom-ngd-ctrl: " Bartosz Golaszewski
2026-07-21  9:26   ` 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=20260721092605.DCBFA1F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=imx@lists.linux.dev \
    --cc=lee@kernel.org \
    --cc=mfd@lists.linux.dev \
    --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 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.