uart_configure does not return -ENOTSUP for stm32 uart with 9 bit data length.

[zisisadamos]

Describe the bug
When we use uart_configure on STM32 for a device with data length of 9 bits we dont get -ENOTSUP

To Reproduce
Steps to reproduce the behavior:

1. Create a 9bit configuration for uart device
2. use that device as an argument for uart_configure
3. Bug. Seems like device is initialized and supports 9bit.

Expected behavior
Return -ENOTSUP

Impact
Not that critical. Lack of 9bit support is more critical.

Environment (please complete the following information):

• OS: Linux
• Toolchain Zephyr SDK
• Commit 95712bd

[tagunil]

Actually the driver itself supports configuring UART to 9 bit mode. Looks like it is the API that is missing.

[erwango]

@zisisadamos I'm a bit confused with this issue. And the fix provided didn't seem correct.
Can you elaborate a bit on the issue you're facing?

[zisisadamos]

Definately. So I am trying to do 9bit data transfers(excluding parity and stop bits) with zephyr. Which at least for stm32 driver doesn't seem to be supported(all transfer functions i found on the driver are for 8 bits). So I assumed that when i try to configure serial for 9bit data width it should return -ENOTSUP. Which it doesnt.

[erwango]

ok, got it. Then I think UART_CFG_DATA_BITS_9 shouldbe purely removed for the API. @dcpleung do you confirm ?

[zisisadamos]

I think we can do 9bit as well I was thinking of implementing it. Just wanted to do that fix for now so I get familiar with contribution flow. 9bit is only impossible for poll api of zephyr because the specify the input type and dont use pointer(poll_out specifically).

[dcpleung]

ok, got it. Then I think UART_CFG_DATA_BITS_9 shouldbe purely removed for the API. @dcpleung do you confirm ?

I think it would be better to extend the API to support 9 bit transfers, for example, using uint16_t instead of uint8_t for buffer type. So I think adding new API functions to do uint16_t when some kconfig is enabled would be the way to go.

[zisisadamos]

ok, got it. Then I think UART_CFG_DATA_BITS_9 shouldbe purely removed for the API. @dcpleung do you confirm ?

I think it would be better to extend the API to support 9 bit transfers, for example, using uint16_t instead of uint8_t for buffer type. So I think adding new API functions to do uint16_t when some kconfig is enabled would be the way to go.

I was thinking about casting the pointer according to configuration. That would only require poll_write to change.

[dcpleung]

The send/receive functions all takes 8-bit character or 8-bit byte array so 9-bit data cannot be sent through them. That's why I think we will need a new set of API which takes uint16_t or uint16_t *. New APIs also avoid the issue with changing current stable API. Also avoid using uint16_t if the app only ever needs 8-bit to save a few bytes for buffers.

[zisisadamos]

The send/receive functions all takes 8-bit character or 8-bit byte array so 9-bit data cannot be sent through them. That's why I think we will need a new set of API which takes uint16_t or uint16_t *. New APIs also avoid the issue with changing current stable API. Also avoid using uint16_t if the app only ever needs 8-bit to save a few bytes for buffers.

All of them except uart_poll_out accept pointers. So if driver does cast uint8_t* to uint16_t* based on configuration why do we need to change APIs? We can only change uart_poll_out to accept a pointer instead of an actual value. Then driver can handle it internally.

[dcpleung]

Conceptually, the array represents a series of datum to send or receive. In 8-bit mode, it's just an array of 8-bit characters. When the driver arbitrarily type casts the input, it becomes less clear on what is expected from the app. Does one datum occupy 2 bytes? Or do you pack multiple 9-bit data continuous into the array? I simply wish the API to be straight-forward, so app developers do not have to have in-depth knowledge of the drivers.

[erwango]

@zisisadamos @dcpleung I propose we create a dedicated UART API issue for the 9 bit support.
#31798 could be pursued but requires rework.

[easternblack]

I think configuring PARITY bits in UART has similar issue.
UART only work with NONE parity, but not with ODD or EVEN.
I tested on stm32l433cb, and /include/stm32l4xx_ll_usart.h include EVEN and ODD defines.
I also experienced data bit issue explained above, and now have doubt with PARITY bit configure has same problem.

[erwango]

@easternblack Don't hesitate to raise a dedicated issue so we don't lose the point.