It is not clear why this is necessary. For example, the
zynq_uart_initialize() does not issue the '\r' before waiting for an
inactive transmission state.
Similar to the recent commit in tms570-sci.c, the assumption that a UART will
only see printable ASCII characters, instead of any value in the range
0x00-0xFF, is wrong.
A non forgiving binary protocol will be thrown off by this driver sending
"\r\r\r\r" when initializing.
If a user wants to flush the interface, they should explicitely use the
dedicated function `tcflush(fd, TCIOFLUSH);`.
Make the initialization and polled functions independent of the Termios
context. This helps to implement the kernel I/O support without a dependency
on the Termios framework.
The existing fix for the ZynqMP UART hardware bug only caught the vast
majority of instances where it could occur. To fully fix the data
corruption, this fix must be applied after every baud rate change. This
makes the logic reset and kick apply in any locations where the baud
rate could be changed.
Constantly reinitializing the Cadence UART on every character output
causes data corruption/loss on some ZynqMP hardware. Only initialize
the UART once for early output and give it a kick on startup.
The zynq-uart set_attributes implementation was configured to always
return false which causes spconsole01 to fail. This restores the
disabled implementation which sets the baud rate registers
appropriately and allows spconsole01 to pass. This also expands the
set_attributes functionality to allow setting of the stop bits,
character width, and parity.
