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

[Tapio Reijonen <tapio.reijonen@vaisala.com>]

On 10/8/26 13:03, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:

All six were reviewed; none is introduced by this series, and the
concurrency ones describe windows this patch already bounds by design:

- the "Critical" remove() use-after-free is the pre-existing
  cancel-before-unregister ordering (see the reply on patch 7);
- the RTS worker reads the envelope state lock-free by design and
  re-derives the pin level on every run: a stale run is flushed on an
  RS485 disable, re-queued after the termios settle, and the hold
  expiry re-asserts under break ownership - RS485-disable landing in
  every envelope phase was exercised on hardware, 20/20 with no
  spurious re-assert;
- the delayed-stop check runs from the TX-empty path, where an empty
  FIFO is ground truth, and the armed hold includes one extra
  character for the shift register; the regression matrix and a two
  hour stress soak show no early release;
- the hrtimer-running window resolves inside the timer callback
  itself, which re-checks the cancel flag and state under port->lock.

Tapio