• Sebastian Andrzej Siewior's avatar
    serial: 8250: drop the printk from serial8250_interrupt() · 9d7c249a
    Sebastian Andrzej Siewior authored
    The printk() in serial8250_interrupt() was once hidden behind a debug
    macro in commit f4f653e9 ("serial: 8250, disable "too much work"
    messages") and reverted back in commit 12de375e ("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: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    9d7c249a
8250_core.c 31.4 KB