[PATCH] Fully disabled seemingly unsupported zynq_uart_set_attributes handler

[Sebastian Huber]

On 27/03/2019 20:26, Chris Johns wrote:
> 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.

So even if we implement the set attributes we have the problem to figure 
out in which state the UART is during initialization? My hope was 
eventually someone will implement it. Since nobody requested the set 
attributes function in a couple of years, I think it is all right to 
just remove it and return no error.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.