The printk() in serial8250_interrupt() was once hidden behind a debug
macro in commit f4f653e987 ("serial: 8250, disable "too much work"
messages") and reverted back in commit 12de375ec4 ("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>
9d7c249a1e