Attention is currently required from: laforge, pespin.

View Change

2 comments:

• Patchset:

  • Patch Set #3:

    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:

  • Patch Set #3, 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.

To view, visit change 35171. To unsubscribe, or for help writing mail filters, visit settings.