diff options
author | Benjamin Herrenschmidt <benh@kernel.crashing.org> | 2010-01-10 17:51:42 +0000 |
---|---|---|
committer | Benjamin Herrenschmidt <benh@kernel.crashing.org> | 2010-01-15 13:26:13 +1100 |
commit | 02ab851324dc7e2fc75787f7fae71187092be7ed (patch) | |
tree | b7019a603013ccdeb176349a5b0e315111b2e538 /drivers/serial | |
parent | 46759a7c132648d79121518d2f7c34edc3f0cf58 (diff) |
serial/pmac_zilog: Workaround problem due to interrupt on closed port
It seems that in qemu, we can see an interrupt in R3 despite the
fact that it's masked in W1. The chip doesn't actually issue an
interrupt, but we can "see" it when taking an interrupt for the
other channel. This may be a qemu bug ... or not, so let's be
safe and avoid calling into the UART layer when that happens which
woulc cause a crash.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Rob Landley <rob@landley.net>
Diffstat (limited to 'drivers/serial')
-rw-r--r-- | drivers/serial/pmac_zilog.c | 11 |
1 files changed, 11 insertions, 0 deletions
diff --git a/drivers/serial/pmac_zilog.c b/drivers/serial/pmac_zilog.c index 0700cd10b97c..683e66f18e8c 100644 --- a/drivers/serial/pmac_zilog.c +++ b/drivers/serial/pmac_zilog.c @@ -411,6 +411,17 @@ static void pmz_transmit_chars(struct uart_pmac_port *uap) goto ack_tx_int; } + /* Under some circumstances, we see interrupts reported for + * a closed channel. The interrupt mask in R1 is clear, but + * R3 still signals the interrupts and we see them when taking + * an interrupt for the other channel (this could be a qemu + * bug but since the ESCC doc doesn't specify precsiely whether + * R3 interrup status bits are masked by R1 interrupt enable + * bits, better safe than sorry). --BenH. + */ + if (!ZS_IS_OPEN(uap)) + goto ack_tx_int; + if (uap->port.x_char) { uap->flags |= PMACZILOG_FLAG_TX_ACTIVE; write_zsdata(uap, uap->port.x_char); |