Skip to content

doc: tighten cts/hw control flow wording - #68

Merged
phip1611 merged 2 commits into
rust-osdev:mainfrom
phip1611:doc
Aug 15, 2026
Merged

doc: tighten cts/hw control flow wording#68
phip1611 merged 2 commits into
rust-osdev:mainfrom
phip1611:doc

Conversation

@phip1611

Copy link
Copy Markdown
Member

Following-up on #66 (comment)

@phip1611 phip1611 self-assigned this Aug 15, 2026
In my latest understanding, I do optional "software-assisted" hardware
control flow with this optional check. The proper "hardware control
flow" would mean that on CTS I receive an ModemStatus change interrupt.

For the synchronous nature of the driver, this is okay. If one builds
a interrupt-driven asynchronous driver around it, one may disable that
and perform the necessary checks in the "send on interrupt" handler.
The optional CTS check implements software-assisted CTS flow control.
On a synchronous driver, checking CTS before transmission is a
reasonable way to honor the remote flow-control signal.

An interrupt-driven driver can instead use ModemStatus interrupts to
track CTS changes and stop/resume transmission accordingly. UARTs with
automatic CTS support can handle this directly in hardware. In practice,
this is uncommon for classic 16550/16550A UARTs and is mainly found in
enhanced 16550-compatible implementations.
@phip1611
phip1611 enabled auto-merge August 15, 2026 08:03
@phip1611
phip1611 added this pull request to the merge queue Aug 15, 2026
Merged via the queue into rust-osdev:main with commit e7a9822 Aug 15, 2026
16 checks passed
@phip1611
phip1611 deleted the doc branch August 15, 2026 08:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant