Not possible to detect interrupt-driven UART API support in a useful way

[xyzzy42]

Is your enhancement proposal related to a problem? Please describe.
There are three UART APIs, polling, interrupt-driven, and async. The latter two are not supported by all UART drivers. Support for the APIs is also a build time configuration option. But even when the API is enabled, any given UART may or may not support it.

Support must be detected at run time. This can be done during initialization for the async API: the call to uart_callback_set() will return -ENOSYS if the UART does not support the async API or -ENOTSUP if the API was not enabled.

But for the interrupt-driven API, uart_irq_callback_user_data_set() returns void. Other methods in the interrupt-driven API have -ENOSYS returns, but they all cause actions on the UART and aren't suitable to use when the UART user is initializing.

Compile time support for the interrupt-driven API in general can be done through IS_ENABLED() of course.

Describe the solution you'd like
uart_irq_callback_user_data_set() should return an error code, like uart_callback_set(). All the information to do this appears to be there and it's a trivial change. Existing users will just ignore the return value.

Describe alternatives you've considered
Support could in most cases be detected at compile tiime. All the information is known. Which UART device is used. What driver that UART has. If that driver supports interrupt-driven and/or async APIs. The API could be determined at compile time and unused code paths optimized away.

Additional context
The uart logging backend would be much faster on a USB CDC ACM UART if it used the interrupt-driven API. But there is no good way to know if it's supported. The backend is used on many different UARTs and not all support interrupt-driven mode.

[carlescufi]

Describe the solution you'd like
uart_irq_callback_user_data_set() should return an error code, like uart_callback_set(). All the information to do this appears to be there and it's a trivial change. Existing users will just ignore the return value.

Thanks for the suggestion. Would you be able to propose a Pull Request with this change?

[xyzzy42]

I take it the compile time detection is too much of a change?

I think it could be done without that much difficulty with a device tree property. This would allow:

• Optimizing away code paths for the APIs that aren't in use in use by a given uart API comsumer.
• Detecting at build time the use of an unsupported API for a given UART. There is no way to do this now. Using an API that the configure time selected uart doesn't support will produce no build errors but will fail at run time.
• Per-UART API selection. Currently enabling the interrupt-driven API enables it globally for every instance of every driver. There's no way to enable the interrupt or async APIs, but still control individual UARTs to use a specific API.

[TorstenRobitzki]

I feel the pain. Implementing something, just to later find out, that a certain device (USB CDC with an nRF53) does not implement one (at least) of the provided interfaces takes a lot of time that could have been saved at configuration time. Till now, I can not even find something in the documentation that states, that the async. UART interface is not supported with the nRF53 USB CDC Uart.