Realtek: serial - line ending fix

[0xc0170]

Description

One line had a window line ending in Realtek HAL Serial implementation.

To reproduce, do a change in a file, and this line gets shown (line change to unix line endings):

 git diff
warning: CRLF will be replaced by LF in targets/TARGET_Realtek/TARGET_AMEBA/TARGET_RTL8195A/serial_api.c.
The file will have its original line endings in your working directory.
diff --git a/targets/TARGET_Realtek/TARGET_AMEBA/TARGET_RTL8195A/serial_api.c b/targets/TARGET_Realtek/TARGET_AMEBA/TARGET_RTL8195A/serial_api.c
index 5f1cccb6f..46f2dde5f 100644
--- a/targets/TARGET_Realtek/TARGET_AMEBA/TARGET_RTL8195A/serial_api.c
+++ b/targets/TARGET_Realtek/TARGET_AMEBA/TARGET_RTL8195A/serial_api.c
@@ -327,7 +327,7 @@ void serial_irq_set(serial_t *obj, SerialIrq irq, uint32_t enable)
         if(enable) {
             if (irq == RxIrq) {
                 log_uart_irq_set(&stdio_uart_log, IIR_RX_RDY, enable);
-                serial_log_irq_en |= SERIAL_RX_IRQ_EN;
+                serial_log_irq_en |= SERIAL_RX_IRQ_EN;
             } else {
                 log_uart_irq_set(&stdio_uart_log, IIR_THR_EMPTY, enable);
                 serial_log_irq_en |= SERIAL_TX_IRQ_EN;

Pull request type

[X] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

[0xc0170]

To confirm, here is a view at line endings on current master

            if (irq == RxIrq) {¬
                log_uart_irq_set(&stdio_uart_log, IIR_RX_RDY, enable);¬
                serial_log_irq_en |= SERIAL_RX_IRQ_EN;CR
¬
            } else {¬
                log_uart_irq_set(&stdio_uart_log, IIR_THR_EMPTY, enable);¬
                serial_log_irq_en |= SERIAL_TX_IRQ_EN;¬
            }¬

The line has CR.

[0xc0170]

/morph build

[0xc0170]

Fixes #6449

[mbed-ci]

Build : SUCCESS

Build number : 1567
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6450/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[mbed-ci]

Test : SUCCESS

Build number : 1358
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6450/1358

[mbed-ci]

Exporter Build : SUCCESS

Build number : 1206
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6450/

[0xc0170]

@OPpuolitaival Please review pr-head

[SeppoTakalo]

As told earlier.. the whitespace change broke the CI, and therefore CI cannot build even this one.

[adbridge]

Sounds like the CI is too easily broken in that case :(

[SeppoTakalo]

What?

This is now broken on all our workspaces.. not just CI.

If you have cloned mbed-os earlier and checkout master branch and then try to check out some other branch, you will see the same issue.

Problem is that if you Git is (properly) configured to convert line endings, then you see this issue.

If your Git is NOT configured, then all our files are randomly either Windows or Unix line endings. Depending on who touched that file previously.

[SeppoTakalo]

https://help.github.com/articles/dealing-with-line-endings/

[marcuschangarm]

As told earlier.. the whitespace change broke the CI, and therefore CI cannot build even this one.

Shouldn't we just get this merged then?

[0xc0170]

Based on the impact, I am happy to get this in (one line change, no code change, only line ending). the flow in our CI is correct (git checkout branches, I got now the same problem locally as was switching between branches ), we will need to review gitattributes or other options to stay away from this line endings breakages.

[kjbracey]

If someone does manage to bypass/ignore .gitattributes and check in an unnormalised file, Git clients that do obey it get confused when they see the unnormalised file in the repo.

Basically they immediately try to normalise it in the work area, which marks the file as locally changed, which blocks some commands.

It's unfortunate that the normal CI sequence for the PR that breaks it doesn't see the problem, while the CI for subsequent PRs does.

You could use astyle to do a line-ending check, but I think the CI should (also?) programmatically use Git to check for this specific normalisation problem.

The return code of git diff-files --quiet immediately after a fresh check-out would indicate the problem - it will return non-zero indicating you have a local change (due to .gitattributes normalisation), which you wouldn't have if the checked-in files were normalised.