Merge tock#1131

1131: Use proper pin for CC26xx UART RX r=ppannuto a=alevy

### Pull Request Overview

This fixes a regression in the CC26xx UART introduced by a tiny oversight in tock#1073. The implementation of `configure` was using the stored `tx_pin` twice, for configuring both TX and RX pins. Since RX is configured second, this overrode resulted in the user-chosen TX pin being configured to act as the RX side of the UART, and no TX configured at all.

The result is that the console or debug appeared not to work.

### Testing Strategy

I programmed the launchxl board with a kernel from current `master` as well as the `c_hello` app. Running that results in no output on the UART.

With the fix in this PR, and the same app, output is "Hello World!", as expected.

I ran similar small tests with `panic!` and `debug!`.

### TODO or Help Wanted

_For after this PR_

I'm concerned about the duplication of the PCRM module---the UART module refers to the CC26xx PCRM module, while other drivers refer to the CC26x2 PCRM module. I originally assumed this was the problem until running `git bisect`. I really think we should just get rid of CC26xx for now. But that's for another PR.

### Documentation Updated

- [x] ~~Updated the relevant files in `/docs`, or no updates are required.~~

### Formatting

- [x] Ran `make formatall`.


Co-authored-by: Amit Aryeh Levy <[email protected]>

Author: bors[bot]

chips/cc26xx/src/uart.rs

@@ -107,7 +107,7 @@ impl UART {
         }
 
         self.tx_pin.map_or(ReturnCode::EOFF, |tx_pin| {
-            self.tx_pin.map_or(ReturnCode::EOFF, |rx_pin| {
+            self.rx_pin.map_or(ReturnCode::EOFF, |rx_pin| {
                 unsafe {
                     // Make sure the TX pin is output/high before assigning it to UART control
                     // to avoid falling edge glitches