GitLab

qla4_82xx_rom_lock() spins on a certain hardware state until it is
updated. At the end of each spin, if in_interrupt() is true, it does 20
loops of cpu_relax(). Otherwise, it yields the CPU.

While in_interrupt() is ill-defined and does not provide what the name
suggests, it is not needed here: qla4_82xx_rom_lock() is always called
from process context. Below is an analysis of its callers:

  - ql4_nx.c: qla4_82xx_rom_fast_read(), all process context callers:
    => ql4_nx.c: qla4_82xx_pinit_from_rom(), GFP_KERNEL allocation
    => ql4_nx.c: qla4_82xx_load_from_flash(), msleep() in a loop

  - ql4_nx.c: qla4_82xx_pinit_from_rom(), earlier discussed

  - ql4_nx.c: qla4_82xx_rom_lock_recovery(), bound to "isp_operations"
    ->rom_lock_recovery() hook, which has one process context caller,
    qla4_8xxx_device_bootstrap(), with callers:
      => ql4_83xx.c: qla4_83xx_need_reset_handler(), process, msleep()
      => ql4_nx.c: qla4_8xxx_device_sta...