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

On Mon, Jul 13, 2026 at 02:21:24PM +0300, Andy Shevchenko wrote:
> 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.

Not sure how much changes are involved. Maybe it's safer to set up a
runtime PM enabled wrapper for uart_update_mctrl() and then start updating
the uart_update_mctrl() and get/set_mctrl() callers one at a time to make
them runtime PM aware.