summaryrefslogtreecommitdiff
path: root/tools/lib/python
diff options
context:
space:
mode:
authorTapio Reijonen <tapio.reijonen@vaisala.com>2026-10-08 09:48:30 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2026-10-13 15:19:27 +0200
commitc06fcc258db0c0c7f607e64a7ce6a157bb2414b1 (patch)
tree0b5016638c64f1a4bcd9bd66fde21e1a41e82cc7 /tools/lib/python
parent7b07356e820e9543cb5b64d009c345303aad0c65 (diff)
serial: max310x: schedule tx_work directly from the IRQ handler
The TXEMPTY interrupt asks for a FIFO refill, and start_tx() does nothing beyond scheduling tx_work, so going through it makes no functional difference. It does conflate two distinct events, though: start_tx() is the serial core starting a new transmission, while TXEMPTY can only fire for a transmission that is already running - the bit latches on the FIFO's non-empty to empty transition, and the IRQ handler's read of IRQSTS consumes the latch, so a stale TXEMPTY cannot exist on an idle port (if the bit were level-triggered, the handler's read-until-clear loop would never terminate). Schedule tx_work directly, keeping the interrupt path a pure FIFO refill. This is preparation for a following patch that adds software-timed RS485 RTS control, where start_tx() also starts the RTS envelope and a refill must not restart it. No functional change. Assisted-by: Claude:claude-fable-5 Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com> Link: https://patch.msgid.link/20261008-max310x-rs485-sw-delay-v8-7-6ba881f81e1f@vaisala.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions