On Mon, Aug 23, 2021 at 2:53 PM Bin Meng <[email protected]> wrote: > > On Mon, Aug 23, 2021 at 12:43 PM Alistair Francis <[email protected]> > wrote: > > > > On Mon, Aug 23, 2021 at 12:11 PM Bin Meng <[email protected]> wrote: > > > > > > At present when input clock is disabled, any character transmitted > > > to tx fifo can still show on the serial line, which is wrong. > > > > > > Fixes: b636db306e06 ("hw/char/cadence_uart: add clock support") > > > Signed-off-by: Bin Meng <[email protected]> > > > --- > > > > > > hw/char/cadence_uart.c | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/hw/char/cadence_uart.c b/hw/char/cadence_uart.c > > > index b4b5e8a3ee..154be34992 100644 > > > --- a/hw/char/cadence_uart.c > > > +++ b/hw/char/cadence_uart.c > > > @@ -327,6 +327,11 @@ static gboolean cadence_uart_xmit(void *do_not_use, > > > GIOCondition cond, > > > static void uart_write_tx_fifo(CadenceUARTState *s, const uint8_t *buf, > > > int size) > > > { > > > + /* ignore characters when unclocked or in reset */ > > > + if (!clock_is_enabled(s->refclk) || device_is_in_reset(DEVICE(s))) { > > > + return; > > > + } > > > > Should we log a guest error here? > > > > Not sure. Based on my past experience of many hardware, if the input > clock is disabled, accessing the whole register block might cause a > bus fault. But I believe such bus fault is not modeled in QEMU. > > This change just mirrors the same check on the Rx side.
Ok: Reviewed-by: Alistair Francis <[email protected]> Alistair > > Regards, > Bin
