1. 08 Dec, 2020 1 commit
  2. 07 Dec, 2020 15 commits
  3. 02 Dec, 2020 9 commits
  4. 01 Dec, 2020 15 commits
    • James Smart's avatar
      scsi: lpfc: Correct null ndlp reference on routine exit · 9d8de441
      James Smart authored
      smatch correctly called out a logic error with accessing a pointer after
      checking it for null:
      
       drivers/scsi/lpfc/lpfc_els.c:2043 lpfc_cmpl_els_plogi()
       error: we previously assumed 'ndlp' could be null (see line 1942)
      
      Adjust the exit point to avoid the trace printf ndlp reference. A trace
      entry was already generated when the ndlp was checked for null.
      
      Link: https://lore.kernel.org/r/20201130181226.16675-1-james.smart@broadcom.com
      Fixes: 4430f7fd ("scsi: lpfc: Rework locations of ndlp reference taking")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJames Smart <james.smart@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      9d8de441
    • Can Guo's avatar
      scsi: ufs: Stop hardcoding the scale down gear · 29b87e92
      Can Guo authored
      Instead of hardcoding the scale down gear, make it a member of
      the ufs_clk_scaling struct.
      
      Link: https://lore.kernel.org/r/1606442334-22641-1-git-send-email-cang@codeaurora.orgReviewed-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: default avatarBean Huo <beanhuo@micron.com>
      Reviewed-by: default avatarAsutosh Das <asutoshd@codeaurora.org>
      Signed-off-by: default avatarCan Guo <cang@codeaurora.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      29b87e92
    • Can Guo's avatar
      scsi: ufs-qcom: Keep core_clk_unipro on while link is active · 96f08cc5
      Can Guo authored
      If we want to disable clocks to save power but still keep the link active,
      core_clk_unipro, like ref_clk, should not be the one being disabled.
      
      Link: https://lore.kernel.org/r/1606356063-38380-3-git-send-email-cang@codeaurora.orgReviewed-by: default avatarHongwu Su <hongwus@codeaurora.org>
      Reviewed-by: default avatarAsutosh Das <asutoshd@codeaurora.org>
      Signed-off-by: default avatarCan Guo <cang@codeaurora.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      96f08cc5
    • Can Guo's avatar
      scsi: ufs: Refactor ufshcd_setup_clocks() to remove skip_ref_clk · 81309c24
      Can Guo authored
      Remove the param skip_ref_clk from __ufshcd_setup_clocks(), but keep a flag
      in struct ufs_clk_info to tell whether a clock can be disabled or not while
      the link is active.
      
      Link: https://lore.kernel.org/r/1606356063-38380-2-git-send-email-cang@codeaurora.orgReviewed-by: default avatarHongwu Su <hongwus@codeaurora.org>
      Reviewed-by: default avatarBean Huo <beanhuo@micron.com>
      Reviewed-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Signed-off-by: default avatarCan Guo <cang@codeaurora.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      81309c24
    • Sebastian Andrzej Siewior's avatar
      scsi: message: fusion: Remove in_interrupt() usage in mptsas_cleanup_fw_event_q() · 817a7c99
      Sebastian Andrzej Siewior authored
      mptsas_cleanup_fw_event_q() uses in_interrupt() to determine if it is safe
      to cancel a worker item.
      
      Aside of that in_interrupt() is deprecated as it does not provide what the
      name suggests. It covers more than hard/soft interrupt servicing context
      and is semantically ill defined.
      
      Looking closer there are a few problems with the current construct:
      
       - It could be invoked from an interrupt handler / non-blocking context
         because cancel_delayed_work() has no such restriction. Also,
         mptsas_free_fw_event() has no such restriction.
      
       - The list is accessed unlocked. It may dequeue a valid work-item but at
         the time of invoking cancel_delayed_work() the memory may be released or
         reused because the worker has already run.
      
      mptsas_cleanup_fw_event_q() is invoked via mptsas_shutdown() which is
      always invoked from preemtible context on device shutdown.  It is also
      invoked via mptsas_ioc_reset(, MPT_IOC_POST_RESET) which is a
      MptResetHandlers callback. The only caller here are mpt_SoftResetHandler(),
      mpt_HardResetHandler() and mpt_Soft_Hard_ResetHandler(). All these
      functions have a `sleepFlag' argument and each caller uses caller uses
      `CAN_SLEEP' here and according to current documentation: | @sleepFlag:
      Indicates if sleep or schedule must be called
      
      So it is safe to sleep.
      
      Add mptsas_hotplug_event::users member. Initialize it to one by default so
      mptsas_free_fw_event() will free the memory.  mptsas_cleanup_fw_event_q()
      will increment its value for items it dequeues and then it may keep a
      pointer after dropping the lock.  Invoke cancel_delayed_work_sync() to
      cancel the work item and wait if the worker is currently busy. Free the
      memory afterwards since it owns the last reference to it.
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-15-bigeasy@linutronix.de
      Cc: Sathya Prakash <sathya.prakash@broadcom.com>
      Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
      Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
      Cc: MPT-FusionLinux.pdl@broadcom.com
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      817a7c99
    • Thomas Gleixner's avatar
      scsi: message: fusion: Remove in_interrupt() usage in mpt_config() · b8a51443
      Thomas Gleixner authored
      in_interrupt() is referenced all over the place in these drivers. Most of
      these references are comments which are outdated and wrong.
      
      Aside of that in_interrupt() is deprecated as it does not provide what the
      name suggests. It covers more than hard/soft interrupt servicing context
      and is semantically ill defined.
      
      >From reading the mpt_config() code and the history this is clearly a debug
      mechanism and should probably be replaced by might_sleep() or completely
      removed because such checks are already in the subsequent functions.
      
      Remove the in_interrupt() references and replace the usage in mpt_config()
      with might_sleep().
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-14-bigeasy@linutronix.de
      Cc: Sathya Prakash <sathya.prakash@broadcom.com>
      Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
      Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
      Cc: MPT-FusionLinux.pdl@broadcom.com
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      b8a51443
    • Ahmed S. Darwish's avatar
      scsi: myrs: Remove WARN_ON(in_interrupt()) · ca685369
      Ahmed S. Darwish authored
      The in_interrupt() macro is ill-defined and does not provide what the name
      suggests. The usage especially in driver code is deprecated and a tree-wide
      effort to clean up and consolidate the (ab)usage of in_interrupt() and
      related checks is happening.
      
      In this case the check covers only parts of the contexts in which these
      functions cannot be called. It fails to detect preemption or interrupt
      disabled invocations.
      
      As wait_for_completion() already contains a broad variety of checks (always
      enabled or debug option dependent) which cover all invalid conditions
      already, there is no point in having extra inconsistent warnings in
      drivers.
      
      Just remove it.
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-12-bigeasy@linutronix.de
      Cc: Hannes Reinecke <hare@kernel.org>
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarAhmed S. Darwish <a.darwish@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      ca685369
    • Ahmed S. Darwish's avatar
      scsi: myrb: Remove WARN_ON(in_interrupt()) · 3bc08b95
      Ahmed S. Darwish authored
      The in_interrupt() macro is ill-defined and does not provide what the name
      suggests. The usage especially in driver code is deprecated and a tree-wide
      effort to clean up and consolidate the (ab)usage of in_interrupt() and
      related checks is happening.
      
      In this case the check covers only parts of the contexts in which these
      functions cannot be called. It fails to detect preemption or interrupt
      disabled invocations.
      
      As wait_for_completion() already contains a broad variety of checks (always
      enabled or debug option dependent) which cover all invalid conditions
      already, there is no point in having extra inconsistent warnings in
      drivers.
      
      Just remove it.
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-11-bigeasy@linutronix.de
      Cc: Hannes Reinecke <hare@kernel.org>
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarAhmed S. Darwish <a.darwish@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      3bc08b95
    • Ahmed S. Darwish's avatar
      scsi: mpt3sas: Remove in_interrupt() · 547c0d1a
      Ahmed S. Darwish authored
      _scsih_fw_event_cleanup_queue() waits for all outstanding firmware events
      wokrqueue handlers to finish. If in_interrupt() is true, it cancels itself
      and return early.
      
      That in_interrupt() check is ill-defined and does not provide what the name
      suggests: it does not cover all states in which it is safe to block and
      call functions like cancel_work_sync().
      
      That check is also not needed: _scsih_fw_event_cleanup_queue() is always
      invoked from process context. Below is an analysis of its callers:
      
        - scsih_remove(), bound to PCI ->remove(), process context
      
        - scsih_shutdown(), bound to PCI ->shutdown(), process context
      
        - mpt3sas_scsih_clear_outstanding_scsi_tm_commands(), called by
            => _base_clear_outstanding_commands(), called by
              =>_base_fault_reset_work(), workqueue
              => mpt3sas_base_hard_reset_handler(), locks mutex
      
      Remove the in_interrupt() check. Change _scsih_fw_event_cleanup_queue()
      specification to a purely process-context function and mark it with
      "Context: task, can sleep".
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-10-bigeasy@linutronix.de
      Cc: Sathya Prakash <sathya.prakash@broadcom.com>
      Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
      Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
      Cc: <MPT-FusionLinux.pdl@broadcom.com>
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarAhmed S. Darwish <a.darwish@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      547c0d1a
    • Ahmed S. Darwish's avatar
      scsi: qla4xxx: Remove in_interrupt() from qla4_82xx_rom_lock() · 014aced1
      Ahmed S. Darwish authored
      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_state_handler(), multiple msleep()s
      
        - ql4_nx.c: qla4_82xx_read_flash_data(), has cond_resched()
      
      Remove the in_interrupt() check. Mark, qla4_82xx_rom_lock(), and the
      ->rom_lock_recovery() hook, with "Context: task, can sleep".
      
      Change qla4_82xx_rom_lock() implementation to sleep 20ms, instead of a
      schedule(), for each spin. This is more deterministic, and it matches
      the other implementations bound to ->rom_lock_recovery().
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-9-bigeasy@linutronix.de
      Cc: Nilesh Javali <njavali@marvell.com>
      Cc: Manish Rangankar <mrangankar@marvell.com>
      Cc: <GR-QLogic-Storage-Upstream@marvell.com>
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarAhmed S. Darwish <a.darwish@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      014aced1
    • Ahmed S. Darwish's avatar
      scsi: qla4xxx: Remove in_interrupt() from qla4_82xx_idc_lock() · 3627668c
      Ahmed S. Darwish authored
      qla4_82xx_idc_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_idc_lock() is always called from
      process context. Below is an analysis of its callers:
      
        - ql4_nx.c: qla4_82xx_need_reset_handler(), 1-second msleep() in a
          loop.
      
        - ql4_nx.c: qla4_82xx_isp_reset(), calls
          qla4_8xxx_device_state_handler(), which has multiple msleep()s.
      
      Beside direct calls, qla4_82xx_idc_lock() is also bound to isp_operations
      ->idc_lock() hook. Other functions which are bound to the same hook,
      e.g. qla4_83xx_drv_lock(), also have an msleep(). For completeness, below
      is an analysis of all callers of that hook:
      
        - ql4_83xx.c: qla4_83xx_need_reset_handler(), has an msleep()
      
        - ql4_83xx.c: qla4_83xx_isp_reset(), calls
          qla4_8xxx_device_state_handler(), which has multiple msleep()s.
      
        - ql4_83xx.c: qla4_83xx_disable_pause(), all process context callers:
          => ql4_mbx.c: qla4xxx_mailbox_command(), msleep(), mutex_lock()
          => ql4_os.c: qla4xxx_recover_adapter(), schedule_timeout() in loop
          => ql4_os.c: qla4xxx_do_dpc(), workqueue context
      
        - ql4_attr.c: qla4_8xxx_sysfs_write_fw_dump(), sysfs bin_attribute
          ->write() hook, process context
      
        - ql4_mbx.c: qla4xxx_mailbox_command(), earlier discussed
      
        - ql4_nx.c: qla4_8xxx_device_bootstrap(), callers:
          => ql4_83xx.c: qla4_83xx_need_reset_handler(), process, msleep()
          => ql4_nx.c: qla4_8xxx_device_state_handler(), earlier discussed
      
        - ql4_nx.c: qla4_8xxx_need_qsnt_handler(), callers:
          => ql4_nx.c: qla4_8xxx_device_state_handler(), multiple msleep()s
          => ql4_os.c: qla4xxx_do_dpc(), workqueue context
      
        - ql4_nx.c: qla4_8xxx_update_idc_reg(), callers:
          => ql4_nx.c: qla4_8xxx_device_state_handler(), earlier discussed
          => ql4_os.c: qla4_8xxx_error_recovery(), only called by
          qla4xxx_pci_slot_reset(), which is bound to PCI ->slot_reset()
          process-context hook
      
        - ql4_nx.c: qla4_8xxx_device_state_handler(), earlier discussed
      
        - ql4_os.c: qla4xxx_recover_adapter(), earlier discussed
      
        - ql4_os.c: qla4xxx_do_dpc(), earlier discussed
      
      Remove the in_interrupt() check. Mark, qla4_82xx_idc_lock(), and the
      ->idc_lock() hook itself, with "Context: task, can sleep".
      
      Change qla4_82xx_idc_lock() implementation to sleep 100ms, instead of a
      schedule(), for each spin. This is more deterministic, and it matches other
      PCI HW locking functions in the driver.
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-8-bigeasy@linutronix.de
      Cc: Nilesh Javali <njavali@marvell.com>
      Cc: Manish Rangankar <mrangankar@marvell.com>
      Cc: <GR-QLogic-Storage-Upstream@marvell.com>
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarAhmed S. Darwish <a.darwish@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      3627668c
    • Ahmed S. Darwish's avatar
      scsi: qla2xxx: Remove in_interrupt() from qla83xx-specific code · 4f6a57c2
      Ahmed S. Darwish authored
      qla83xx_wait_logic() is used to control the frequency of device IDC lock
      retries. If in_interrupt() is true, it does 20 loops of cpu_relax().
      Otherwise, it sleeps for 100ms and yields the CPU.
      
      While in_interrupt() is ill-defined and does not provide what the name
      suggests, it is not needed here: that qla83xx_wait_logic() is exclusively
      called by qla83xx_idc_lock() / unlock(), and they always run from process
      context. Below is an analysis of all the idc lock/unlock callers, in order
      of appearance:
      
        - qla_os.c:
            qla83xx_nic_core_unrecoverable_work(),
            qla83xx_idc_state_handler_work(),
            qla83xx_nic_core_reset_work(),
            qla83xx_service_idc_aen(), all workqueue context
      
        - qla_os.c: qla83xx_check_nic_core_fw_alive(), has msleep()
      
        - qla_os.c: qla83xx_set_drv_presence(), called once from
          qla2x00_abort_isp(), which is bound to process-context ->abort_isp()
          hook. It also invokes wait_for_completion_timeout() through the chain
          qla2x00_configure_hba() => qla24xx_link_initialize() =>
          qla2x00_mailbox_command().
      
        - qla_os.c: qla83xx_clear_drv_presence(), which is called from
          qla2x00_abort_isp() discussed above, and from qla2x00_remove_one()
          which is PCI process-context ->remove() hook.
      
        - qla_os.c: qla83xx_need_reset_handler(), has a one second msleep() in
          a loop.
      
        - qla_os.c: qla83xx_device_bootstrap(), called only by
          qla83xx_idc_state_handler(), which has multiple msleep()
          invocations.
      
        - qla_os.c: qla83xx_idc_state_handler(), multiple msleep()
          invocations.
      
        - qla_attr.c: qla2x00_sysfs_write_reset(), sysfs bin_attribute
          ->write() hook, process context
      
        - qla_init.c: qla83xx_nic_core_fw_load()
            => qla_init.c: qla2x00_initialize_adapter()
              => bound to isp_operations ->initialize_adapter() hook
              ** => qla_os.c: qla2x00_probe_one(), PCI ->probe() process ctx
      
        - qla_init.c: qla83xx_initiating_reset(), msleep() in a loop.
      
        - qla_init.c: qla83xx_nic_core_reset(), called by
          qla83xx_nic_core_reset_work(), workqueue context.
      
      Remove the in_interrupt() check, and thus replace the entirety of
      qla83xx_wait_logic() with an msleep(QLA83XX_WAIT_LOGIC_MS).
      
      Mark qla83xx_idc_lock() / unlock() with "Context: task, can sleep".
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-7-bigeasy@linutronix.de
      Cc: Nilesh Javali <njavali@marvell.com>
      Cc: GR-QLogic-Storage-Upstream@marvell.com
      Reviewed-by: default avatarHimanshu Madhani <himanshu.madhani@oracle.com>
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarAhmed S. Darwish <a.darwish@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      4f6a57c2
    • Ahmed S. Darwish's avatar
      scsi: target: tcm_qla2xxx: Remove BUG_ON(in_interrupt()) · 9fef41f2
      Ahmed S. Darwish authored
      tcm_qla2xxx_free_session() has a BUG_ON(in_interrupt()).
      
      While in_interrupt() is ill-defined and does not provide what the name
      suggests, it is not needed here: the function is always invoked from
      workqueue context through "struct qla_tgt_func_tmpl" ->free_session() hook
      it is bound to.
      
      The function also calls wait_event_timeout() down the chain, which already
      has a might_sleep().
      
      Remove the in_interrupt() check.
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-6-bigeasy@linutronix.de
      Cc: Nilesh Javali <njavali@marvell.com>
      Cc: <GR-QLogic-Storage-Upstream@marvell.com>
      Reviewed-by: default avatarHimanshu Madhani <himanshu.madhani@oracle.com>
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarAhmed S. Darwish <a.darwish@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      9fef41f2
    • Ahmed S. Darwish's avatar
      scsi: qla2xxx: Remove in_interrupt() from qla82xx-specific code · 8ac246bd
      Ahmed S. Darwish authored
      qla82xx_idc_lock() spins on a certain hardware state until it's 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: qla82xx_idc_lock() is always called from
      process context. Below is an analysis of its callers, in order of
      appearance:
      
        - qla_nx.c: qla82xx_device_bootstrap(), only called by
          qla82xx_device_state_handler(), has multiple msleep()s.
      
        - qla_nx.c: qla82xx_need_qsnt_handler(), has one second msleep()
      
        - qla_nx.c: qla82xx_wait_for_state_change(), one second msleep()
      
        - qla_nx.c: qla82xx_need_reset_handler(), can sleep up to 10 seconds
      
        - qla_nx.c: qla82xx_device_state_handler(), has multiple msleep()s
      
        - qla_nx.c: qla82xx_abort_isp(), if it's a qla82xx controller, calls
          qla82xx_device_state_handler(), which sleeps. It's also bound to
          isp_operations ->abort_isp() hook, where all the callers are in process
          context.
      
        - qla_nx.c: qla82xx_beacon_on(), bound to isp_operations ->beacon_on()
          hook.  That hook is only called once, in a mutex locked context, from
          qla2x00_beacon_store().
      
        - qla_nx.c: qla82xx_beacon_off(), bound to isp_operations ->beacon_off()
          hook.  Like ->beacon_on(), it's only called once, in a mutex locked
          context, from qla2x00_beacon_store().
      
        - qla_nx.c: qla82xx_fw_dump(), calls qla2x00_wait_for_chip_reset(), which
          has msleep() in a loop. It is bound to isp_operations ->fw_dump()
          hook. That hook *is* called from atomic context at qla_isr.c by
          multiple interrupt handlers. Nonetheless, it's other controllers
          interrupt handlers, and not the qla82xx.
      
        - qla82xx_msix_default() and qla82xx_msix_rsp_q() call
          qla24xx_process_response_queue() which doesn't implement the firmware
          dumping.
      
        - qla_attr.c: qla2x00_sysfs_write_fw_dump(), and
          qla2x00_sysfs_write_reset(), process-context sysfs ->write() hooks.
      
        - qla_os.c: qla2x00_probe_one(). PCI ->probe(), process context.
      
        - qla_os.c: qla2x00_clear_drv_active(), called solely from
          qla2x00_remove_one(), which is PCI ->remove() hook, process context.
      
        - qla_os.c: qla2x00_do_dpc(), kthread function, process context.
      
      Remove the in_interrupt() check. Change qla82xx_idc_lock() specification to
      a purely process-context function. Mark it with "Context: task, might
      sleep".
      
      Change qla82xx_idc_lock() implementation to sleep 100ms, instead of a
      schedule(), for each spin. This is more deterministic, and it matches the
      other qla models idc_lock() functions.
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-5-bigeasy@linutronix.de
      Cc: Nilesh Javali <njavali@marvell.com>
      Cc: <GR-QLogic-Storage-Upstream@marvell.com>
      Reviewed-by: default avatarHimanshu Madhani <himanshu.madhani@oracle.com>
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarAhmed S. Darwish <a.darwish@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      8ac246bd
    • Ahmed S. Darwish's avatar
      scsi: qla4xxx: Remove in_interrupt() · a93c3835
      Ahmed S. Darwish authored
      qla4_82xx_crb_win_lock() spins on a certain hardware state until it's
      updated. At the end of each spin, if in_interrupt() is true, it does 20
      loops of cpu_relax(). Otherwise, it yields the CPU.
      
      The in_interrupt() macro is ill-defined as it does not provide what the
      name suggests, and it does not catch the intended use-case here.
      
      qla4_82xx_crb_win_lock() is always invoked with scsi_qla_host::hw_lock
      acquired, with disabled interrupts. If the caller is in process context, as
      in qla4_82xx_need_reset_handler(), then in_interrupt() will return false
      even though it is not allowed to call schedule().
      
      Remove the in_interrupt() check.
      
      Change qla4_82xx_crb_win_lock() specification to a purely atomic
      function. Mark it as static, remove its forward declaration, and move it
      above its callers. To avoid hammering the PCI bus while spinning, use a 10
      micro-second delay instead of cpu_relax().
      
      Link: https://lore.kernel.org/r/20201126132952.2287996-4-bigeasy@linutronix.de
      Fixes: f4f5df23 ("[SCSI] qla4xxx: Added support for ISP82XX")
      Cc: Nilesh Javali <njavali@marvell.com>
      Cc: Manish Rangankar <mrangankar@marvell.com>
      Cc: <GR-QLogic-Storage-Upstream@marvell.com>
      Reviewed-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarAhmed S. Darwish <a.darwish@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      a93c3835