Re: Review of concept of changing UART flow control from Kconfig to DTS config


Hi Marti,
Let's say there is a board (all our boards are Nordic-based so this applies to all of them) which has a UART brought out to a header, the UART might be used for a multitude of things, it could be a debug port which is mostly unused, or it could be connected to a PC for exchanging a lot of data, or it could be connected to a shield, perhaps a modem, which does not have flow control pins - this is one board (and one .dts file) but with different requirements for flow control, in the old system this worked fine and flow control could be enabled or disabled on a per-project configuration or even by board/shield overlays (one board but many different projects). With the new system, that isn't possible, this requires unique board .dts files because you can no longer disable or enable flow control via a Kconfig option (yet strangely parity is still a Kconfig option, the change itself doesn't really make sense to me).
The issue is not that it is opt-in or opt-out, the issue is that it is opt-in at a DTS level (and thus a board level) and not opt-in at a project level. If we enable flow control for our board, we need to add overlays to every sample project for all of our boards whereby flow control isn't needed which becomes a mess.

-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@...>
Sent: 13 May 2021 17:11
To: Jamie Mccrae <Jamie.Mccrae@...>; devel@...
Cc: Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
Subject: Re: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config

EXTERNAL EMAIL: Be careful with attachments and links.

Hi (and +Krzysztof in Cc),

"lairdjm via"
<> writes:

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

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:

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.

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
It looks like flow control is off by default and it's opt-in; what did I miss?



Join { to automatically receive all group messages.