Commit bbf275f0 authored by Mike Frysinger's avatar Mike Frysinger Committed by Bryan Wu

Blackfin serial driver: pending a unique anomaly id, tie the break flood issue to ANOMALY_05000230

pending a unique anomaly id, tie the break flood issue to ANOMALY_05000230
as when that was fixed, the fallout also fixed the break flood
Signed-off-by: default avatarMike Frysinger <michael.frysinger@analog.com>
Signed-off-by: default avatarBryan Wu <bryan.wu@analog.com>
parent 85a75996
......@@ -231,12 +231,10 @@ static void bfin_serial_rx_chars(struct bfin_serial_port *uart)
{
struct tty_struct *tty = uart->port.info->tty;
unsigned int status, ch, flg;
static int in_break = 0;
#ifdef CONFIG_KGDB_UART
struct pt_regs *regs = get_irq_regs();
#endif
#ifdef BF533_FAMILY
static int in_break = 0;
#endif
status = UART_GET_LSR(uart);
ch = UART_GET_CHAR(uart);
......@@ -263,12 +261,14 @@ static void bfin_serial_rx_chars(struct bfin_serial_port *uart)
}
#endif
#ifdef BF533_FAMILY
if (ANOMALY_05000230) {
/* The BF533 family of processors have a nice misbehavior where
* they continuously generate characters for a "single" break.
* We have to basically ignore this flood until the "next" valid
* character comes across. All other Blackfin families operate
* properly though.
* Note: While Anomaly 05000230 does not directly address this,
* the changes that went in for it also fixed this issue.
*/
if (in_break) {
if (ch != 0) {
......@@ -279,12 +279,11 @@ static void bfin_serial_rx_chars(struct bfin_serial_port *uart)
} else
return;
}
#endif
}
if (status & BI) {
#ifdef BF533_FAMILY
if (ANOMALY_05000230)
in_break = 1;
#endif
uart->port.icount.brk++;
if (uart_handle_break(&uart->port))
goto ignore_char;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment