serial: 8250: drop the printk from serial8250_interrupt()
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>
Thu, 2 Aug 2018 11:14:32 +0000 (13:14 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 18 Sep 2018 14:07:23 +0000 (16:07 +0200)
commit9d7c249a1ef9bf0d5696df14e6bc067004f16979
treecce29c335777efa1969fca40ca99fc2f8f2e5a99
parent2dd453168643d9475028cd867c57e65956a0f7f9
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>
drivers/tty/serial/8250/8250_core.c