Re: Review of concept of changing UART flow control from Kconfig to DTS config
Hi Marti,toggle quoted messageShow quoted text
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.
From: Bolivar, Marti <Marti.Bolivar@nordicsemi.no>
Sent: 13 May 2021 17:11
To: Jamie Mccrae <Jamie.Mccrae@lairdconnect.com>; firstname.lastname@example.org
Cc: Chruściński, Krzysztof <Krzysztof.Chruscinski@nordicsemi.no>
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 lists.zephyrproject.org"
Hi,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 applicationI'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.
It looks like flow control is off by default and it's opt-in; what did I miss?