[PATCH 1/2] pmdomain: imx8mp-blk-ctrl: set awake path for power_dev if attached device needs wakeup

Current design will power off all dependent GPC power domains in
imx8mp_blk_ctrl_suspend(), even though the user device has enabled
wakeup capability. The result is that wakeup function never works
for such device.

An example will be USB wakeup on i.MX8MP. PHY device '382f0040.usb-phy'
is attached to power domain 'hsioblk-usb-phy2' which is spawned by hsio
block control. A virtual power domain device 'genpd:3:32f10000.blk-ctrl'
is created to build connection with 'hsioblk-usb-phy2' and it depends on
GPC power domain 'usb-otg2'. If device '382f0040.usb-phy' enable wakeup,
only power domain 'hsioblk-usb-phy2' keeps on during system suspend,
power domain 'usb-otg2' is off all the time. So the wakeup event can't
happen.

Let's propagate wakeup path to virtual power domain device so the wakeup
event can happen properly.

Fixes: 556f5cf9568a ("soc: imx: add i.MX8MP HSIO blk-ctrl")
Cc: stable@kernel.org
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
 drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
index 34576be606e3..f3bfd6d22722 100644
--- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
+++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c

@@ -804,12 +804,20 @@ static int imx8mp_blk_ctrl_suspend(struct device *dev)
 
 	for (i = 0; i < bc->onecell_data.num_domains; i++) {
 		struct imx8mp_blk_ctrl_domain *domain = &bc->domains[i];
+		struct pm_domain_data *pdd;
 
 		ret = pm_runtime_get_sync(domain->power_dev);
 		if (ret < 0) {
 			pm_runtime_put_noidle(domain->power_dev);
 			goto out_fail;
 		}
+
+		list_for_each_entry(pdd, &domain->genpd.dev_list, list_node) {
+			if (device_awake_path(pdd->dev)) {
+				device_set_awake_path(domain->power_dev);
+				break;
+			}
+		}
 	}
 
 	return 0;

-- 
2.34.1

USB remote wakeup need its PHY on, so add USB PHY power domain
on active flag.

Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Li Jun <redacted>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
 drivers/pmdomain/imx/gpcv2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pmdomain/imx/gpcv2.c b/drivers/pmdomain/imx/gpcv2.c
index a829f8da5be7..5c66ee0a3731 100644
--- a/drivers/pmdomain/imx/gpcv2.c
+++ b/drivers/pmdomain/imx/gpcv2.c

@@ -953,6 +953,7 @@ static const struct imx_pgc_domain imx8mp_pgc_domains[] = {
 	[IMX8MP_POWER_DOMAIN_USB1_PHY] = {
 		.genpd = {
 			.name = "usb-otg1",
+			.flags = GENPD_FLAG_ACTIVE_WAKEUP,
 		},
 		.bits = {
 			.pxx = IMX8MP_USB1_PHY_Pxx_REQ,

@@ -964,6 +965,7 @@ static const struct imx_pgc_domain imx8mp_pgc_domains[] = {
 	[IMX8MP_POWER_DOMAIN_USB2_PHY] = {
 		.genpd = {
 			.name = "usb-otg2",
+			.flags = GENPD_FLAG_ACTIVE_WAKEUP,
 		},
 		.bits = {
 			.pxx = IMX8MP_USB2_PHY_Pxx_REQ,

-- 
2.34.1

On Mon, 2 Feb 2026 at 08:46, Xu Yang [off-list ref] wrote:

This is really messy in my opinion. Ideally the above should not be
used by a genpd provider as it's internal data structures are managed
by genpd itself.

If I understand correctly, this problem boils down to the fact that we
should have tried harder to model child/parent domains, rather than
using runtime PM to manage the parent domains. I understand there are
problems with that, due to specific power on/off sequences we have for
imx power-domains, but I wonder if those could be managed better by
using genpd on/off notifiers?

Anyway, that said. Rather than walking through the list of devices as
above, I suggest that you use the ->power_off() callback for the
corresponding genpd(s) to dev in combination with a genpd power on/off
notifier for the corresponding genpd that the power_dev is attached
to.

More precisely, if the "child domain(s)" that corresponds to "dev" has
not been powered-off (because device_awake_path() is set for some
device) during system suspend, the power-off notifier should return
NOTIFY_BAD to prevent the "parent domain" that corresponds to
power_dev from being powered-off.

Would that work, you think?

Kind regards
Uffe

On Tue, Feb 03, 2026 at 12:06:28PM +0100, Ulf Hansson wrote:

On Mon, 2 Feb 2026 at 08:46, Xu Yang [off-list ref] wrote:

quoted

+
+               list_for_each_entry(pdd, &domain->genpd.dev_list, list_node) {
+                       if (device_awake_path(pdd->dev)) {
+                               device_set_awake_path(domain->power_dev);
+                               break;
+                       }
+               }

This is really messy in my opinion. Ideally the above should not be
used by a genpd provider as it's internal data structures are managed
by genpd itself.

If I understand correctly, this problem boils down to the fact that we
should have tried harder to model child/parent domains, rather than
using runtime PM to manage the parent domains. I understand there are
problems with that, due to specific power on/off sequences we have for
imx power-domains, but I wonder if those could be managed better by
using genpd on/off notifiers?

Indeed. I have tried using subdomain will resolve the wakeup issue because
the parent domain will manage the child domain. But I shouldn't use
subdomain and runtime PM way together to avoid any unexpected behaviors
according to my understanding.

Anyway, that said. Rather than walking through the list of devices as
above, I suggest that you use the ->power_off() callback for the
corresponding genpd(s) to dev in combination with a genpd power on/off
notifier for the corresponding genpd that the power_dev is attached
to.

More precisely, if the "child domain(s)" that corresponds to "dev" has
not been powered-off (because device_awake_path() is set for some
device) during system suspend, the power-off notifier should return
NOTIFY_BAD to prevent the "parent domain" that corresponds to
power_dev from being powered-off.

Would that work, you think?

Thank you for the suggestion. It works for me.

With this way the rejected count is increasing. Does this have any impact?
The count is just used for statistics, right?

# cat /sys/kernel/debug/pm_genpd/usb-otg2/idle_states
State          Time Spent(ms) Usage      Rejected   Above      Below
S0             1203           0          1          0          0

Thanks,
Xu Yang

On Wed, 4 Feb 2026 at 09:48, Xu Yang [off-list ref] wrote:

On Tue, Feb 03, 2026 at 12:06:28PM +0100, Ulf Hansson wrote:

quoted

On Mon, 2 Feb 2026 at 08:46, Xu Yang [off-list ref] wrote:

quoted

+
+               list_for_each_entry(pdd, &domain->genpd.dev_list, list_node) {
+                       if (device_awake_path(pdd->dev)) {
+                               device_set_awake_path(domain->power_dev);
+                               break;
+                       }
+               }

This is really messy in my opinion. Ideally the above should not be
used by a genpd provider as it's internal data structures are managed
by genpd itself.

If I understand correctly, this problem boils down to the fact that we
should have tried harder to model child/parent domains, rather than
using runtime PM to manage the parent domains. I understand there are
problems with that, due to specific power on/off sequences we have for
imx power-domains, but I wonder if those could be managed better by
using genpd on/off notifiers?

Indeed. I have tried using subdomain will resolve the wakeup issue because
the parent domain will manage the child domain. But I shouldn't use
subdomain and runtime PM way together to avoid any unexpected behaviors
according to my understanding.

Well, there is nothing wrong with using child/parent domain in
combination with runtime PM.

Although in general using runtime PM to manage parents domains from
child domains, should be better managed by genpd itself.

quoted

Anyway, that said. Rather than walking through the list of devices as
above, I suggest that you use the ->power_off() callback for the
corresponding genpd(s) to dev in combination with a genpd power on/off
notifier for the corresponding genpd that the power_dev is attached
to.

More precisely, if the "child domain(s)" that corresponds to "dev" has
not been powered-off (because device_awake_path() is set for some
device) during system suspend, the power-off notifier should return
NOTIFY_BAD to prevent the "parent domain" that corresponds to
power_dev from being powered-off.

Would that work, you think?

Thank you for the suggestion. It works for me.

Great!

With this way the rejected count is increasing. Does this have any impact?
The count is just used for statistics, right?

Yes, it's used for statistics.

# cat /sys/kernel/debug/pm_genpd/usb-otg2/idle_states
State          Time Spent(ms) Usage      Rejected   Above      Below
S0             1203           0          1          0          0

Thanks,
Xu Yang

Kind regards
Uffe