Re: [PATCH 0/6] tty: serial: propagate errors from uart_ops.pm callback
Tony Lindgren <[email protected]> Mon, 13 Jul 2026 12:29:20 +0300
| Newsgroups | org.kernel.vger.linux-omap,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-samsung-soc,org.kernel.vger.linux-serial |
|---|---|
| Message-ID | <alSv8BPCOiyKvOI2@tlindgre-MOBL1> |
On Fri, Jul 10, 2026 at 07:37:46AM +0300, Tony Lindgren wrote: > * Andy Shevchenko <[email protected]> [260709 10:38]: > > 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? > > The RX side of things should work for hardware that can wake up to an incoming > event. Linux for sure needs more work to properly handle the various corner case > TX wake-up of a PM runtime idled UART. I'm mostly offline until Monday though, > will check my notes for more details next week. For the TX side handling, my understanding is that at least uart_update_mctrl() needs to call PM runtime resume and put autosuspend. And we should assume uart_update_mctrl() can sleep to resume the PM runtime suspended serial port. For drivers, the callers of uport->ops->get/set_mctrl() should be updated to use uart_update_mctrl() where possible. And the remaining ones that cannot sleep should be fixed so they can sleep or have PM runtime disabled. Anybody have better ideas? Regards, Tony