Thomas Richard <thomas.richard@xxxxxxxxxxx> writes: [...] > I finally found the culprit. > Just adding the GENPD_FLAG_ACTIVE_WAKEUP flag by default caused the > panic, even without the call of device_set_wakeup_path(). > > With some debug, I found that the wakeup_path of all my uarts (even > other uarts not used by the console) was set. > So the corresponding power domains were not powered off [1]. > Consequently they are not powered on during the resume [2]. > > But on my platform (J7200), the SoC is fully off during suspend-to-ram. > Even if a power domain is not powered off by Linux, at the end all the > SoC is off. > And if Linux doesn't power off a power domain, it doesn't power on it. OK, so the core of the problem is here. The SoC firmware is going to power of the domain during system-wide suspend, no matter what Linux tries to do. So there's a fundamental disconnect between what Linux thinks is the state of the power domain and the actual hardware state. I'm not sure how to work around that other than if the firmware is always going to power off the domain, then GENPD_FLAG_ACTIVE_WAKEUP cannot be used for that domain, since it's effectively ignored. > The wakeup_path of all my uarts is set here [3] because devices are > wakeup capable [4]. Ok, but now This behavior is now changed in v6.12-rc1[6] (introduced by this[7] series.) Now, UARTs default to wakeup capable (not enabled), and wakeups are only enabled if the DT property `wakeup-source` is used. This should at least allow you to focus on only UARTs that are intended as wakeup sources for the platform, instead of the current (pre v.6.12) behavior where all UARTs default to wakeup-enabled. Kevin > It was added by commit 8512220c5782d [5]. > If I remove the wakeup_path modification (diff at the end of the email), > Théo's proposal works well. But it's probably too rough, and I have no > idea about the impact on other platforms. > > If you have an idea to fix correctly this wakeup_path issue, please let > me know :) > > [1] > https://elixir.bootlin.com/linux/v6.11/source/drivers/pmdomain/core.c#L1372 > [2] > https://elixir.bootlin.com/linux/v6.11/source/drivers/pmdomain/core.c#L1427 > [3] > https://elixir.bootlin.com/linux/v6.10.10/source/drivers/base/power/main.c#L1687 > [4] > https://elixir.bootlin.com/linux/v6.11/source/drivers/tty/serial/8250/8250_omap.c#L1526 > [5] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8512220c5782d [6] https://elixir.bootlin.com/linux/v6.12-rc1/source/drivers/tty/serial/8250/8250_omap.c#L1525 [7] https://lore.kernel.org/all/20240807141227.1093006-1-msp@xxxxxxxxxxxx/
