ice: do not re-enable miscellaneous interrupt until thread_fn completes
authorJacob Keller <jacob.e.keller@intel.com>
Thu, 1 Jun 2023 21:15:07 +0000 (14:15 -0700)
committerTony Nguyen <anthony.l.nguyen@intel.com>
Thu, 8 Jun 2023 20:03:31 +0000 (13:03 -0700)
commit0ec38df36ea1cc4f21bf7cd61a89942b034883c5
tree677c4e44c1a9986b83728fd4bd638c650f5bd313
parent9a8648cce8d8a4a7770b45239912e20edb9736ad
ice: do not re-enable miscellaneous interrupt until thread_fn completes

The ice driver uses threaded IRQ for managing Tx timestamps via the
devm_request_threaded_irq() interface. The ice_misc_intr() handler function
is responsible for processing the hard interrupt context, and can wake the
ice_misc_intr_thread_fn() by returning IRQ_WAKE_THREAD.

The request_threaded_irq() function comment says:

  @handler is still called in hard interrupt context and has to check
  whether the interrupt originates from the device. If yes, it needs to
  disable the interrupt on the device and return IRQ_WAKE_THREAD which will
  wake up the handler thread and run the @thread_fn.

We currently re-enable the Other Interrupt Cause Register (OCIR) at the end of
ice_misc_intr(). In practice, this seems to be ok, but it can make
communicating between the handler function and the thread function
difficult. This is because the interrupt can trigger again while the thread
function is still processing.

Move the OICR update to the end of the thread function, leaving the other
interrupt cause disabled in hardware until we complete one pass of the
thread function. This prevents the miscellaneous interrupt from firing
until after we finish the thread function.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
drivers/net/ethernet/intel/ice/ice_main.c