• Douglas Anderson's avatar
    drm/msm/dp: Return IRQ_NONE for unhandled interrupts · bfc12020
    Douglas Anderson authored
    If our interrupt handler gets called and we don't really handle the
    interrupt then we should return IRQ_NONE. The current interrupt
    handler didn't do this, so let's fix it.
    
    NOTE: for some of the cases it's clear that we should return IRQ_NONE
    and some cases it's clear that we should return IRQ_HANDLED. However,
    there are a few that fall somewhere in between. Specifically, the
    documentation for when to return IRQ_NONE vs. IRQ_HANDLED is probably
    best spelled out in the commit message of commit d9e4ad5b ("Document
    that IRQ_NONE should be returned when IRQ not actually handled"). That
    commit makes it clear that we should return IRQ_HANDLED if we've done
    something to make the interrupt stop happening.
    
    The case where it's unclear is, for instance, in dp_aux_isr() after
    we've read the interrupt using dp_catalog_aux_get_irq() and confirmed
    that "isr" is non-zero. The function dp_catalog_aux_get_irq() not only
    reads the interrupts but it also "ack"s all the interrupts that are
    returned. For an "unknown" interrupt this has a very good chance of
    actually stopping the interrupt from happening. That would mean we've
    identified that it's our device and done something to stop them from
    happening and should return IRQ_HANDLED. Specifically, it should be
    noted that most interrupts that need "ack"ing are ones that are
    one-time events and doing an "ack" is enough to clear them. However,
    since these interrupts are unknown then, by definition, it's unknown
    if "ack"ing them is truly enough to clear them. It's possible that we
    also need to remove the original source of the interrupt. In this
    case, IRQ_NONE would be a better choice.
    
    Given that returning an occasional IRQ_NONE isn't the absolute end of
    the world, however, let's choose that course of action. The IRQ
    framework will forgive a few IRQ_NONE returns now and again (and it
    won't even log them, which is why we have to log them ourselves). This
    means that if we _do_ end hitting an interrupt where "ack"ing isn't
    enough the kernel will eventually detect the problem and shut our
    device down.
    Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
    Tested-by: default avatarKuogee Hsieh <quic_khsieh@quicinc.com>
    Reviewed-by: default avatarKuogee Hsieh <quic_khsieh@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/520660/
    Link: https://lore.kernel.org/r/20230126170745.v2.2.I2d7aec2fadb9c237cd0090a47d6a8ba2054bf0f8@changeid
    [DB: reformatted commit message to make checkpatch happy]
    Signed-off-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
    bfc12020
dp_aux.c 12.7 KB