haraldwolff/qemu-patch-raspberry4
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

serial: fix retry logic

Browse source 
I'm not sure if the retry logic has ever worked when not using FIFO mode.  I
found this while writing a test case although code inspection confirms it is
definitely broken.

The TSR retry logic will never actually happen because it is guarded by an
'if (s->tsr_rety > 0)' but this is the only place that can ever make the
variable greater than zero.  That effectively makes the retry logic an 'if (0)'.

I believe this is a typo and the intention was >= 0.  Once this is fixed though,
I see double transmits with my test case.  This is because in the non FIFO
case, serial_xmit may get invoked while LSR.THRE is still high because the
character was processed but the retransmit timer was still active.

We can handle this by simply checking for LSR.THRE and returning early.  It's
possible that the FIFO paths also need some attention.

Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This commit is contained in:
Anthony Liguori 2012-04-01 14:03:21 -05:00
parent 6e92466a7c
commit 67c5322d70
1 changed files with 3 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
hw/serial.c
View file

@ -327,6 +327,8 @@ static void serial_xmit(void *opaque)
s->tsr = fifo_get(s,XMIT_FIFO);
if (!s->xmit_fifo.count)
s->lsr |= UART_LSR_THRE;
} else if ((s->lsr & UART_LSR_THRE)) {
return;
} else {
s->tsr = s->thr;
s->lsr |= UART_LSR_THRE;
@ -337,7 +339,7 @@ static void serial_xmit(void *opaque)
/* in loopback mode, say that we just received a char */
serial_receive1(s, &s->tsr, 1);
} else if (qemu_chr_fe_write(s->chr, &s->tsr, 1) != 1) {
if ((s->tsr_retry > 0) && (s->tsr_retry <= MAX_XMIT_RETRY)) {
if ((s->tsr_retry >= 0) && (s->tsr_retry <= MAX_XMIT_RETRY)) {
s->tsr_retry++;
qemu_mod_timer(s->transmit_timer, new_xmit_ts + s->char_transmit_time);
return;