Re: [PATCH 0/6] tty: serial: propagate errors from uart_ops.pm callback
Andy Shevchenko <[email protected]> Mon, 13 Jul 2026 14:21:24 +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 |
|---|---|
| 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 Mon, Jul 13, 2026 at 12:29:20PM +0300, Tony Lindgren wrote: > 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? I don't, but the above sounds like a plan. Is it a big task? I can help with something in that area, perhaps Ilpo also would be able to participate. -- With Best Regards, Andy Shevchenko