Does UART1_DCD break UART driver?

While testing custom carrier board for Apalis SoM module, we have discovered very strange behavior. It seems that change on UART1_DCD pin will somehow break UART driver in kernel and kernel become stuck (it autodetects stall on CPU and stops responding to everything).

Hardware details:

Our carrier board uses MAX3242 to convert UART1 to RS232 signal. The schematics is same as Apalis Evaluation Board and Ixora Carrier Board, except for RI signal, which we are not using at all (it is not connected to the MAX3242 and used as GPIO instead).

Unfortunately we do not have different carrier board for Apalis available, so I can not test it on Ixora or Eval board.

Observed behavior:

We use UART1 as debug/serial console in RS232 levels, so I have used USB/RS232 converted to connect to the console. While the output from Apalis module works as expected, trying to interact with the console by sending data over RS232 sometimes causes the Linux to become stuck.

We have tracked the issue down to the UART1_DCD pin. It seems that if the MAX3242 pull the DCD pin down to GND, the UART driver in kernel gets confused somehow and kernel become stuck. I have measured RS232 signals using oscilloscope and I believe that neither Apalis nor the USB/RS232 converter drives DCD signal, and it just receives noise from TX (data to Apalis) signal by capacitive coupling. In some cases, the noise level is enough to flip the TTL output on MAX3242. If this happens, the Linux kernel somehow can not handle it.

What I have tested:

I have tried disabling RTS/CTS on UART1 using device-tree (by removing fsl,uart-has-rtscts option), but nothing has changed.

What avoids the issue is IOMUXing the DCD pin to different function, for example GPIO (in this case GPIO3_IO23), which in fact fixes the issue. I have tried changing IOMUX using device-tree and also with memtool utility during runtime, so everything except IOMUX for the pin remained the same. While the pin was muxed to GPIO, there were no issues with RS232 at all, but when I changed the muxing back to DCD, the kernel got stuck in few seconds again (I was periodically sending data to RS232 whole time).

Expected behavior:

To be honest, I do not really know if the DCD signal is used these days at all. But even if it is not used, I believe that the driver implementation should not be sensitive to noise on any of the signal pins.

Any ideas what is wrong here?

We have observed that issue too. The issue arises from the fact that we are using the UART in DTE mode, which triggers a bug in the UART driver. The issue has been addressed by this kernel change:

With this change, the DCD pin will not trigger any interrupts and hence Linux should run flawless. The fix will be part of our next BSP release.

@stefan.agner Thanks a lot for technical details and patch.