[PATCH] serial: qcom-geni: power the console back up on system resume

[PATCH] serial: qcom-geni: power the console back up on system resume

[David Heidelberg via B4 Relay]

From: David Heidelberg <david@ixit.cz>

The console holds a runtime PM reference on its port, which keeps the
port powered while the tty is closed. On system suspend
pm_runtime_force_suspend() powers the port down regardless, but a single
reference makes pm_runtime_need_not_resume() report the port as not in
use, so it is marked runtime suspended instead of being flagged for
pm_runtime_force_resume(). On system resume the port therefore stays
powered down while uart_resume_port() goes on to program the termios
settings and re-enable the console.

If the tty has been opened before, uart_resume_port() ends up in
startup(), whose runtime PM reference powers the port up again, and only
the register writes made before that are lost. If the tty has never been
opened (no getty on the port, /dev/console backed by another console),
nothing powers the port back up and the console stays dead after the
first suspend.

Resume the port explicitly before uart_resume_port() when the console
was force suspended.

Assisted-by: LLM
Fixes: aee1f94dab13 ("serial: qcom-geni: remove .pm callback, use runtime PM in startup/shutdown")
Signed-off-by: David Heidelberg <david@ixit.cz>
---
 drivers/tty/serial/qcom_geni_serial.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index a180a00c9e23d..0c9164a1fccda 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -2100,16 +2100,22 @@ static int qcom_geni_serial_resume(struct device *dev)
 	struct qcom_geni_private_data *private_data = uport->private_data;
 
 	if (console_suspend_enabled || !uart_console(uport)) {
 		ret = pm_runtime_force_resume(dev);
 		if (ret)
 			return ret;
 	}
 
+	if (console_suspend_enabled && uart_console(uport)) {
+		ret = pm_runtime_resume(dev);
+		if (ret < 0)
+			return ret;
+	}
+
 	ret = uart_resume_port(private_data->drv, uport);
 	if (uart_console(uport)) {
 		geni_icc_set_tag(&port->se, QCOM_ICC_TAG_ALWAYS);
 		geni_icc_set_bw(&port->se);
 	}
 	return ret;
 }
 

---
base-commit: 3d83758432b5e6ed9507500a57efb0f3af41ee7d
change-id: 20260918-qcom-geni-pm-e0ff5899c948
prerequisite-change-id: 20260828-serial-qcom-geni-fix-unbalanced-rpm-resume-814e630326b9:v1
prerequisite-patch-id: a2666a59a68190a3f438cec8aa167111c21dc8ca

Best regards,
--  
David Heidelberg <david@ixit.cz>

Re: [PATCH] serial: qcom-geni: power the console back up on system resume

[Praveen Talari]

Hi David,

On 18-09-2026 03:44, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> The console holds a runtime PM reference on its port, which keeps the
> port powered while the tty is closed. On system suspend
> pm_runtime_force_suspend() powers the port down regardless, but a single
> reference makes pm_runtime_need_not_resume() report the port as not in
> use, so it is marked runtime suspended instead of being flagged for
> pm_runtime_force_resume(). On system resume the port therefore stays
> powered down while uart_resume_port() goes on to program the termios
> settings and re-enable the console.
>
> If the tty has been opened before, uart_resume_port() ends up in
> startup(), whose runtime PM reference powers the port up again, and only
> the register writes made before that are lost. If the tty has never been
> opened (no getty on the port, /dev/console backed by another console),
> nothing powers the port back up and the console stays dead after the
> first suspend.
>
> Resume the port explicitly before uart_resume_port() when the console
> was force suspended.
Thanks for tracking this down. I'm trying to understand the resume flow 
here.

In qcom_geni_serial_resume(), when console_suspend_enabled is set,
we already call pm_runtime_force_resume(dev); before reaching
uart_resume_port().

Given that, could you clarify why an additional:pm_runtime_resume(dev);
is required for the console case?

Specifically, is pm_runtime_force_resume() leaving the device in a
runtime-suspended state despite restoring it from system suspend, or
is there some interaction with the console's runtime PM reference count
that prevents the port from being resumed before uart_resume_port() accesses
the registers?

A bit more detail on why pm_runtime_force_resume() alone is insufficient

would help understand the root cause.


Thanks,

Praveen Talari

>
> Assisted-by: LLM
> Fixes: aee1f94dab13 ("serial: qcom-geni: remove .pm callback, use runtime PM in startup/shutdown")
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
>   drivers/tty/serial/qcom_geni_serial.c | 6 ++++++
>   1 file changed, 6 insertions(+)
>
> diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
> index a180a00c9e23d..0c9164a1fccda 100644
> --- a/drivers/tty/serial/qcom_geni_serial.c
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -2100,16 +2100,22 @@ static int qcom_geni_serial_resume(struct device *dev)
>   	struct qcom_geni_private_data *private_data = uport->private_data;
>   
>   	if (console_suspend_enabled || !uart_console(uport)) {
>   		ret = pm_runtime_force_resume(dev);
>   		if (ret)
>   			return ret;
>   	}
>   
> +	if (console_suspend_enabled && uart_console(uport)) {
> +		ret = pm_runtime_resume(dev);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
>   	ret = uart_resume_port(private_data->drv, uport);
>   	if (uart_console(uport)) {
>   		geni_icc_set_tag(&port->se, QCOM_ICC_TAG_ALWAYS);
>   		geni_icc_set_bw(&port->se);
>   	}
>   	return ret;
>   }
>   
>
> ---
> base-commit: 3d83758432b5e6ed9507500a57efb0f3af41ee7d
> change-id: 20260918-qcom-geni-pm-e0ff5899c948
> prerequisite-change-id: 20260828-serial-qcom-geni-fix-unbalanced-rpm-resume-814e630326b9:v1
> prerequisite-patch-id: a2666a59a68190a3f438cec8aa167111c21dc8ca
>
> Best regards,
> --
> David Heidelberg <david@ixit.cz>
>
>

Re: [PATCH] serial: qcom-geni: power the console back up on system resume

[Konrad Dybcio]

On 9/18/26 3:28 PM, Praveen Talari wrote:
> Hi David,
> 
> On 18-09-2026 03:44, David Heidelberg via B4 Relay wrote:
>> From: David Heidelberg <david@ixit.cz>

[...]

> Specifically, is pm_runtime_force_resume() leaving the device in a
> runtime-suspended state despite restoring it from system suspend, or
> is there some interaction with the console's runtime PM reference count
> that prevents the port from being resumed before uart_resume_port() accesses
> the registers?
> 
> A bit more detail on why pm_runtime_force_resume() alone is insufficient
> 
> would help understand the root cause.

GPT came up with the following explanation:

1. qcom_geni_console_setup() takes a runtime-PM reference with
   pm_runtime_resume_and_get(). If the console is registered but no TTY
   is open, that leaves the port with a usage count of 1.

2. With console_suspend_enabled, qcom_geni_serial_suspend() calls
   pm_runtime_force_suspend() after serial-core suspends the port.

3. pm_runtime_force_suspend() considers a device with usage count <= 1
   and no children eligible to remain suspended after system resume. It
   sets the runtime status to suspended without setting
   needs_force_resume.

4. Accordingly, pm_runtime_force_resume() skips the runtime-resume
   callback. It re-enables runtime PM, but does not power the GENI port
   back up.

5. uart_resume_port() restores console termios before its conditional
   TTY startup. If the TTY was never opened, that startup—and its
   runtime-PM get—doesn't happen. The console remains powered down. If a
   TTY was open, startup eventually wakes it, but only after the earlier
   register accesses.

Konrad