* Johan Hovold [off-list ref] [210924 14:38]:

On Thu, Sep 23, 2021 at 06:02:27PM +0300, Tony Lindgren wrote:

quoted

* Johan Hovold [off-list ref] [210923 12:46]:

quoted

On Tue, Sep 21, 2021 at 01:33:43PM +0300, Tony Lindgren wrote:

quoted

If the serial driver implements PM runtime with autosuspend, the port may
be powered off for TX. To wake up the port, let's add new prep_tx() call
for serial drivers to implement as needed. We call it from serial
write_room() and write() functions. If the serial port is not enabled,
we just return 0.

This isn't right. If there's room in the driver buffer, there's no
reason to not accept those characters.

Maybe. We might get away with returning zero bytes written in write().
But to me it seems better to stop things early when write is known
to not succeed.

But you shouldn't return zero from write() either. If there's room in
the write buffer we accept the data.

And then waking up the serial port takes several tens of ms and the
buffer is full and we still need to deal with it :) But yeah I see
your point for the write buffer.

quoted

quoted

It's the drivers responsibility to resume writing when write() is
called and that me need to be done in a runtime resume callback in case
the device is suspended.

I think we currently need to return zero bytes written from write()
when the serial port is not usable.

I don't think we can return a fake number of bytes written from write().

It's not a fake number. It's similar to if you have a port that is
stalled due to flow control. We buffer the data and continue writing
when the other end is ready to accept more.

OK. So based on what you suggested earlier I'll take a look at moving
the wake-up to __uart_start(), then have the device driver runtime PM
resume call uart_start() again. Looks like uart_start() is a void
function anyways.. If you have some better ideas there, please let me
know.

quoted

quoted

No need to be patching line disciplines for this.

Do you see issues with handling the errors in line disciplines?

It's just conceptually wrong to push retrying up the stack, possible all
the way to user space in case of non-blocking opens, just because the
device isn't already runtime active.

Yes, I don't see a way around that currently. Maybe if we start making
use of uart_tx_stopped() or something similar that could be simplified.
And we'll be still hit these line discipline error handling cases
anyways depending on how long the serial port wake up takes.

Regards,

Tony