Hi (and +Krzysztof in Cc),

"lairdjm via lists.zephyrproject.org"
<jamie.mccrae=lairdconnect.com@...> writes:

Hi,
I only noticed today that the Kconfig option for enabling hardware
flow control on UARTs, which used to be an optional Kconfig option,
was removed and replaced with a DTS boards file configuration option
instead, as per
https://github.com/zephyrproject-rtos/zephyr/pull/25999

To be clear, this PR is limited to nRF SoCs only, it is not a
project-wide change.

I find this to be a bit of a step backwards for application
development, we have many boards in zephyr that we and customers use,
these boards might be used for something simple like a sensor or might
be used alongside a PC for doing some heavy processing and message
passing over Bluetooth, so with a sensor, the log system might be
active but it won't have anything connected to it most of the time
unless there's an issue, so flow control is not required here, if it's
enabled then it's going to cause an issue once the UART buffer gets
full. However, on a PC communications module, that would be using the
UART constantly, and need data integrity so needs flow control - in
the old system, the boards file would have the flow control pins and
it would be disabled by default, a project could enable it with a
Kconfig option, this was great. However with the new system, it seems
that we need to force flow control on all our boards, and then in
instances where it's not needed, have an overlay for that specific
board (and we have many boards) to delete the hardware flow control
part. This means that to enable hardware flow control, we need to
update our boards file then add an overlay to almost every sample
application in zephyr for most of our boards to disable flow control.
This seems a bit chaotic to me so I would like to revisit this concept
of having flow control configurable as a Kconfig option, the pins
should be defined in the DTS file which hasn't changed but if flow
control is needed or not should be controlled on a project basis, opt
in not opt out.

I'm having a bit of trouble understanding what you mean here.

The boolean hw-flow-control property is still available for enabling
hardware flow control for both UART and UARTE:

https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uarte.html#dtbinding-nordic-nrf-uarte
https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uart.html#dtbinding-nordic-nrf-uart

Looking at the code, if hw-flow-control is disabled in DTS (the
default), then in both drivers cfg->flow_ctrl is false. The HAL
configuration structure ends up with flow control disabled in that case:

https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uart.c#L346
https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uarte.c#L397

So flow control at a SoC level seems to be turned off by default.

It's true that many boards in PR #25999 do enable it by default, e.g.
nRF52840-DK:

https://github.com/zephyrproject-rtos/zephyr/pull/25999/files#diff-f496b12068cf78fdbb22c1b8a4eaeb66010db95b4e80db7377a340ae30a83519R7

But it seems like at a board maintainer level, you can leave the SoC
default as-is to make flow control "opt in" as requested.

Are there any thoughts on this subject and how to get this working,
focused on ease of being able to set this for ours and customer's
reuse?

It looks like flow control is off by default and it's opt-in; what did I
miss?

Thanks!
Martí

Thanks,
Jamie