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>
This commit is contained in:
Tapio Reijonen 2026-10-08 09:48:30 +00:00 committed by Greg Kroah-Hartman
parent 7b07356e82
commit c06fcc258d

View File

@ -856,8 +856,12 @@ static irqreturn_t max310x_port_irq(struct max310x_port *s, int portno)
}
if (rxlen)
max310x_handle_rx(port, rxlen);
/*
* TXEMPTY latches on the FIFO becoming empty, so a stale
* interrupt cannot pump data during an RTS setup delay.
*/
if (ists & MAX310X_IRQ_TXEMPTY_BIT)
max310x_start_tx(port);
schedule_work(&s->p[portno].tx_work);
} while (1);
return res;