| Message ID | 1263181902.724.94.camel@pasglop (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Commit | 02ab851324dc7e2fc75787f7fae71187092be7ed |
| Delegated to: | Benjamin Herrenschmidt |
| Headers | show |
On Sunday 10 January 2010 21:51:42 Benjamin Herrenschmidt wrote: > 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> Tested it, and it worked for me. Thanks, Rob
diff --git a/drivers/serial/pmac_zilog.c b/drivers/serial/pmac_zilog.c index 0700cd1..683e66f 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);
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> --- David: This would affect sunzilog as well I believe. I'm not sure if it's a bug in qemu emulation of the ESCC or if a real ESCC can show it so I decided to be safe :-) The ESCC doc I have doesn't appear to specify whether the interrupt status bits in R3 are prior or post masking by W1. I can reproduce that by having the kernel low level "udbg" debug console on channel B and the main console on channel A (which is itself an uncommon setup).