Re: [PATCH v6 2/9] serial: max310x: assert the transceiver during a break

[sashiko-bot@kernel.org]

> The chip's auto-RTS (MODE1.TRNSCVCTRL) asserts the RS485 transceiver
> only while FIFO data is shifting out, and a break is not FIFO data: on
> an RS485 port a requested break sets the TX break bit but the
> transceiver is never enabled, so the break never reaches the wire.
> Break-led protocols cannot work at all.
> 
> Disable auto-RTS for the break duration and drive RTS manually via the
> LCR RTS bit, then restore auto-RTS when the break ends. Track the break
> in tx_break and leave MODE1 alone in the rs485-config worker while it
> is set - a TIOCSRS485 arriving mid-break would otherwise re-enable
> auto-RTS on top of the manual RTS and release the transceiver before
> the break ends; break_ctl() restores auto-RTS from the then-current
> configuration when the break completes. The worker runs under
> port->mutex - break_ctl() and set_termios() already do - so the
> tx_break test and the MODE1 write cannot straddle a break starting or
> ending, and startup() clears tx_break alongside the latched TXBREAK
> bit, since a port can be closed with a break still asserted.
> 
> Only the break assertion is gated on RS485 being enabled; the restore
> at break end runs unconditionally and derives MODE1 from the current
> configuration. Returning early for a port whose RS485 was disabled
> mid-break - that reconfigure is deferred like any other - would leak
> the manually driven RTS and leave the transceiver holding the bus
> indefinitely after the break ends. On a non-RS485 port the restore is
> a no-op: nothing else writes the LCR RTS bit.
> 
> Fixes: 55367c620aed ("serial: max310x: Add support for RS-485 mode")
> Assisted-by: Claude:claude-fable-5
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261004-max310x-rs485-sw-delay-v6-0-3a0ef13ed9e3@vaisala.com?part=2