aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/tty/serial/8250/8250_core.c
diff options
context:
space:
mode:
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>2018-08-02 13:14:32 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-09-18 16:07:23 +0200
commit9d7c249a1ef9bf0d5696df14e6bc067004f16979 (patch)
treecce29c335777efa1969fca40ca99fc2f8f2e5a99 /drivers/tty/serial/8250/8250_core.c
parentkgdboc: Fix restrict error (diff)
downloadlinux-dev-9d7c249a1ef9bf0d5696df14e6bc067004f16979.tar.xz
linux-dev-9d7c249a1ef9bf0d5696df14e6bc067004f16979.zip
serial: 8250: drop the printk from serial8250_interrupt()
The printk() in serial8250_interrupt() was once hidden behind a debug macro in commit f4f653e9875e5 ("serial: 8250, disable "too much work" messages") and reverted back in commit 12de375ec493a ("Revert "serial: 8250, disable "too much work" messages""). This was introduced first in 0.99.13k with the "serial" driver itself (and called pass_number with a limit of 64 and no print). In 1.1.13 it was renamed to pass_counter and the printk was behind #if 0. In 1.1.94 the limit of 64 was increased to 256 and hidden behind RS_ISR_PASS_LIMIT. With this change the #if 0 turned into #if 1. It slowly become what we have today with a loop limit of 512. Usually, that printk isn't hit. However on KVM with a busy UART and overloaded host it might happen. It is also likely with threaded interrupts and a task which preempts the interrupt handler. If the UART has (legitimate) work to do and we break out of the loop, nothing changes: the interrupt is most likely already pending in the interrupt controller and we end up in the handler anyway. This printk is hardly helping. Older kernels also had a comment saying that a bad configuration might lead to this but I don't see how that should happen because a wrongly configured interrupt number would let the handler leave "early" with IRQ_NONE and the spurious detected will handle that (weill since 2.6.11, before that we had no spurious detector). In that case, we would never loop that often here. This loop looks like an optimisation in order to pull the bytes from the FIFO which were received while we were already here instead of waiting for the interrupt. This might have been a good idea while the CPUs were slow and FIFOs small. There are other serial driver in tree, like the amba-pl*, which also have this kind of a loop but without the printk (and were based on this driver). Remove the printk which might trigger in otherwise valid situtations. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to '')
-rw-r--r--drivers/tty/serial/8250/8250_core.c6
1 files changed, 1 insertions, 5 deletions
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 8fe3d0ed229e..94f3e1c64490 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -130,12 +130,8 @@ static irqreturn_t serial8250_interrupt(int irq, void *dev_id)
l = l->next;
- if (l == i->head && pass_counter++ > PASS_LIMIT) {
- /* If we hit this, we're dead. */
- printk_ratelimited(KERN_ERR
- "serial8250: too much work for irq%d\n", irq);
+ if (l == i->head && pass_counter++ > PASS_LIMIT)
break;
- }
} while (l != end);
spin_unlock(&i->lock);