Attention is currently required from: laforge, pespin.

fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/35171?usp=email )

Change subject: soft_uart: check Rx/Tx state once in osmo_soft_uart_{rx,tx}_ubits() ......................................................................

Patch Set 3:

(2 comments)

Patchset:

PS3:

Btw, -EAGAIN doesn't sound like the best error code to return in that situation. […]

The idea here is to indicate the caller that for whatever reason (here it's "the Rx/Tx is disabled", in the next patch it would also be "Rx/TX is suspended by flow control") the receiver/transmitter did not consume/emit the requested amount of bits. And `EAGAIN` should be interpreted as "try next time, things may change".

The caller of `osmo_soft_uart_{rx,tx}_ubits()` is expected not to be in charge of the soft-UART management (enabling or disabling Rx/Tx lines). In a typical scenario it's a logic driving some synchronous medium (like a TCH channel, on which you always Rx and always Tx something).

* If the `_rx_ubits()` API returns `-EAGAIN` (or any other `N != 0`), the caller is likely to ignore this and keep feeding the UART with bits received over the synchronous medium. * If the `_tx_ubits()` API returns `-EAGAIN` (or any other `N != 0`), it's responsibility of the caller to initialize the unpopulated bit buffer with stop bits (binary '1') and transmit them over the synchronous medium.

I am open for suggestions if you have a better errno value in mind ;)

File src/core/soft_uart.c:

https://gerrit.osmocom.org/c/libosmocore/+/35171/comment/47f53bd2_09d4bf26 PS3, Line 291: if (!suart->tx.running)

Move this above the other if condition, this one one can use tx_ubits(... […]

I would better go for adding proper API, if there would be a need for checking Rx/Tx running state. `-EAGAIN` would also be returned if the Rx/Tx is suspended due to flow control (see the next patch), so... no. Let's keep it as-is.