Re: [PATCH v7 8/9] serial: max310x: drive RTS in software when hardware delays are too short

[sashiko-bot@kernel.org]

> The chip's auto-RTS path can express at most 15 bit-times of RTS setup
> and hold delay - a fraction of a millisecond at typical baud rates -
> while the uapi expresses the delays in milliseconds up to the UART
> core's RS485_MAX_RTS_DELAY. Requests beyond the field were rejected
> with -ERANGE, which makes the core silently wipe port->rs485 and
> disable RS485; a device tree asking for a 20 ms setup delay ends up
> with no RS485 at all and an unusable bus.
> 
> Add a software-driven RTS path that takes over whenever the hardware
> cannot represent the requested timing, and clamp the delays to
> RS485_MAX_RTS_DELAY instead of rejecting them.
> 
> max310x_set_rts_ctl_params() picks the path: software if either delay
> exceeds what 15 bit-times encode at the current baud rate, or if the
> requested RTS polarity combination cannot be produced by the auto-RTS
> [ ... ]
> there.
> 
> 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/20261005-max310x-rs485-sw-delay-v7-0-6ae392eca08c@vaisala.com?part=8