Re: [PATCH 2/2] serial: pmac_zilog: report received breaks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] tty: serial: false break injection on NUL after Rx overrun
--

commit 009d6cf5b2db60250bcc44251e6de09814cc2746
Author: Tim Douglas <me@timdoug.com>

serial: pmac_zilog: report received breaks

This commit modifies pmz_receive_chars() to set the BRK_ABRT flag in r1
when processing the null character that ends a break. This allows breaks
to be properly counted and passed to BRKINT, PARMRK, and SysRq handlers,
matching the behavior of sunzilog.

> diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
> index f49d6052d11be..a612f1db9f189 100644
> --- a/drivers/tty/serial/pmac_zilog.c
> +++ b/drivers/tty/serial/pmac_zilog.c
> @@ -233,6 +233,7 @@ static bool pmz_receive_chars(struct uart_pmac_port *uap)
>  		ch &= uap->parity_mask;
>  		if (ch == 0 && uap->flags & PMACZILOG_FLAG_BREAK) {
>  			uap->flags &= ~PMACZILOG_FLAG_BREAK;
> +			r1 |= BRK_ABRT;
>  		}

[Severity: Medium]
Does this code risk injecting a false Break event if an Rx FIFO overrun
occurs?

pmz_status_handle() sets PMACZILOG_FLAG_BREAK when it receives an EXT status
interrupt for a Break. Then pmz_receive_chars() waits for the associated NUL
character to clear the flag.

If an Rx FIFO overrun occurs and the hardware drops the expected NUL character,
the PMACZILOG_FLAG_BREAK flag will remain set indefinitely.

Since BRK_ABRT is now artificially injected into r1 when this flag is finally
cleared, could a subsequent, perfectly valid NUL character (such as Ctrl-@)
arriving much later falsely trigger a Break?

This might cause dropped data or trigger an unintended SysRq. Before this patch,
the stuck flag was harmless because it was cleared without altering r1.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013013541.4535-1-me@timdoug.com?part=2