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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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