Re: [PATCH 0/6] tty: serial: propagate errors from uart_ops.pm callback

Andy Shevchenko <[email protected]>
Newsgroups org.kernel.vger.linux-samsung-soc,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-mediatek,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-mips,org.kernel.vger.linux-omap,org.kernel.vger.linux-serial
Organization Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo
Message-ID <[email protected]>
On Thu, Jul 09, 2026 at 11:55:12AM +0530, Praveen Talari wrote:
> The uart_ops.pm callback has been declared void since its introduction,
> which means any error from a driver's power management implementation is
> silently discarded by uart_change_pm(). Beyond losing the error
> information, uart_change_pm() unconditionally updates state->pm_state
> even when the underlying hardware transition failed. This causes the
> serial core to track a power state that does not reflect reality:
> subsequent calls to uart_change_pm() see the stale cached state as
> matching the requested state and skip the callback entirely, leaving the
> hardware permanently stuck with no further recovery attempt.
> 
> On modern platforms where the .pm callback performs real work —
> enabling clock trees, interacting with runtime PM, asserting voltage
> regulators — this is a correctness gap. Failures are invisible to the
> PM framework, the port proceeds to call ops->startup() on potentially
> unpowered hardware, and suspend/resume errors are hidden from the core
> that needs to handle them.
> 
> This series fixes the problem in four steps:
> 
>   Patch 1 changes the uart_ops.pm callback signature from void to int,
>   updates uart_change_pm() to propagate errors and only commit
>   state->pm_state on success, and handles the return value at every
>   call site in serial_core.c with appropriate policy per context
>   (propagate, log, or skip-on-failure).
> 
>   Patch 2 updates the 8250 driver family: serial8250_do_pm() and
>   serial8250_pm() are updated to return int (with the exported symbol
>   declaration updated in serial_8250.h), and the 8250 sub-driver
>   pm callbacks are updated to return 0.
> 
>   Patch 3 updates the remaining non-8250 serial drivers. All .pm
>   implementations are updated to return 0. The sh-sci forward
>   declaration shared with rsci is also updated.
> 
>   Patch 4 updates arch-level implementations: SA1100 (assabet, h3xxx),
>   OMAP1/ams-delta (modem_pm, now propagates regulator errors), and
>   MIPS/Alchemy (alchemy_8250_pm).
> 
> All existing .pm implementations return 0, so there is no functional
> change for any current driver. The series purely adds the infrastructure
> for drivers to report errors going forward, with the serial core ready
> to handle them correctly.

Just no, please just properly implement runtime PM. The .pm() must die completely.
I used to have the PoC for that long time ago [1], but due to lack of time and
other priorities it went abandoned. Also Atlassian made a brain damages move to
limit repository to 1Gb, so I haven't able to update it for a few years.

Note, that Tony (you have him in the Cc list) did a lot for some corner cases
with that and we still have them IIRC. Tony, do you know what is the state of
affairs with runtime PM for UART?

[1]: https://bitbucket.org/andy-shev/linux/branch/topic/uart/rpm-plus

-- 
With Best Regards,
Andy Shevchenko
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.