[PATCH] Fully disabled seemingly unsupported zynq_uart_set_attributes handler

[Chris Johns]

On 28/3/19 5:40 pm, Sebastian Huber wrote:
> 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? 

I cannot figure out what the default for RTEMS should be and then how that
matches the bootloader and SystemZ settings.

> My hope was eventually someone will implement it.

Yes it would be good however we need a user who uses the UART for something
other than a console.

> 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.

Yeap.

Chris