sys: Revert #11310 (make stdio_rx optional)

[jcarrano]

Contribution description

This change was breaking (dependencies for) ethos, and other serial users, as well as an unknown number of external apps (API change.).

See #11525 for more details.

The reverted PR's functionality can be reintroduced once issues have been addressed. In other words, this revert is not to contest the feature itself, but its current embodiment.

Testing procedure

(taken from #11525)

run:

make -C tests/xtimer_usleep flash
make -C tests/xtimer_usleep test

After the revert the test works again (i.e. it waits for input before initiating)

Issues/PRs references

Fixes #11525.

[MrKevinWeiss]

Looked over the revert, it looks accurate. I was able to find the error in master when testing on the nucleo-f091rc. I think we should revert until a better solution is provided! ACK.

[kaspar030]

Why not use the proposed "keep change but restore original behaviour" by making stdio_uart_rx a default module?

[aabadie]

I'm against this because of low power on STM32, which I think is more important than having getchar working alone (e.g. without the shell) in a couple of tests.

[MrKevinWeiss]

I think it was just nobody did that. I would also like @aabadie opinion since he seemed to really like the rx being disabled.

Not actually resolved

[aabadie]

As I said in the original issue, I think having getchar working can be easily achieved by pulling a dedicated in an application requiring it. This is the usual RIOT way: only pull what's necessary.

[MrKevinWeiss]

Ok as it stands it breaks certain things... Aside from reverting how should we fix this?

[jcarrano]

I insist: if people want to have uart-rx disabled so they can have low power then OK. The issue here is having a tidy solution but also not keeping #11525 until such solution is found.

By reverting #11310 we can have the time give a nice answer to this UART vs PM issue without the pressure of having things broken and an upcoming release.

[aabadie]

having things broken and an upcoming release.

IMHO the "broken things" are a corner case and very minor compared to having low-power working correctly (and easily).

[aabadie]

Note that other solutions were already proposed but didn't get that much comments.

[cladmi]

If a pull request breaks 2 applications in RIOT makes 5 applications inconsistently configured, and 2 documentations wrong, it is a problem.
Addressing these issues should have been done in the original pull request.
Getting back to the state before pull request state is a good trade-off.

Two weeks ago, the problem was issued and no reaction or fix or pull request proposal was done.
Meaning, nobody wants to really maintain RIOT for this change or assume its review.

Note that other solutions were already proposed but didn't get that much comments.

These should have been in the first pull request, or answered by people interested in the change.

[cladmi]

ACK nobody proposed a fix pull request for the 7 application and 2 documentation break.

The pull request can be re-issued in a working state.

[aabadie]

#11598 is proposing the fix I had in mind. I hope it'll make everyone happy :)

[aabadie]

nobody proposed a fix pull request for the 7 application and 2 documentation break.

#11598 does it now. And to help making the fix more accurate, it would be great to precisely list those applications, what's broken, and those 2 documentation misses. I could only find 3 applications related using git grep.

[cladmi]

Why not use the proposed "keep change but restore original behaviour" by making stdio_uart_rx a default module?

This breaks boards using stdio_rtt without providing periph_uart.
So this is not a valid solution.