[PATCH] Fully disabled seemingly unsupported zynq_uart_set_attributes handler

[Chris Johns]

On 28/3/19 5:28 am, Joel Sherrill wrote:
> On Wed, Mar 27, 2019 at 1:10 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
> wrote:
>     On 26/03/2019 15:17, Lou Woods wrote:
>     > From: Lou Woods <Lou.Woods at OARCorp.com>
>     >
>     > ---
>     >   bsps/arm/xilinx-zynq/console/zynq-uart.c | 16 +++++++++++-----
>     >   1 file changed, 11 insertions(+), 5 deletions(-)
>     >
>     > diff --git a/bsps/arm/xilinx-zynq/console/zynq-uart.c
>     b/bsps/arm/xilinx-zynq/console/zynq-uart.c
>     > index fa91f3f..9c21f6f 100644
>     > --- a/bsps/arm/xilinx-zynq/console/zynq-uart.c
>     > +++ b/bsps/arm/xilinx-zynq/console/zynq-uart.c
>     > @@ -262,12 +262,16 @@ static void zynq_uart_write_support(
>     >   #endif
>     >   }
>     >   
>     > +/*
>     > + * Disable this because the initialization is done by code generated
>     > + * by the Xilinx code generator.
>     > + */
> 
>     The main purpose of the set attributes function is to apply the settings
>     specified by the user via the Termios interface. Returning false just
>     indicates that this function is not implemented. If you want to hide
>     this fact from the user, then you can simply return true ...

This assumes all UART hardware supports all possible options. There are many
UARTs that do not. I am not sure if there are errno's that could determine the
nature of the failure.

> We discussed this alternative with Chris and this was the end result.
> 
> git blame shows that Chris added the if 0 and then you added the return false
> which broke the callers. From that point forward, no interactive test ran
> successfully. 

The driver provides no attribute functionality so removing the function means
the default behavior in termios is used to manage the error. It was decided
having the default behavior was best until the driver provided the functionality.

The Zynq is sort of strange in relation to default settings for UARTs. The
SystemZ component in the Xilinx design tool provides settings for the UART and
this ends up in the ps7_init.c file generated by the SDK and built into the FSBL
bootloader. This code paints all registers including the UART at boot time.
Adding UART attribute setting code to the RTEMS driver would result in the
SystemZ settings being overridden by RTEMS which is confusing. I am not sure how
this can be handled without there being some conflict. RTEMS would need to set
the baudrate to 115200 to match the SystemZ default.

Chris