1. 10 5月, 2020 1 次提交
    • J
      lpfc: Refactor lpfc nvme headers · 2a1160a0
      James Smart 提交于
      A lot of files in lpfc include nvme headers, building up relationships that
      require a file to change for its headers when there is no other change
      necessary. It would be better to localize the nvme headers.
      
      There is also no need for separate nvme (initiator) and nvmet (tgt)
      header files.
      
      Refactor the inclusion of nvme headers so that all nvme items are
      included by lpfc_nvme.h
      
      Merge lpfc_nvmet.h into lpfc_nvme.h so that there is a single header used
      by both the nvme and nvmet sides. This prepares for structure sharing
      between the two roles. Prep to add shared function prototypes for upcoming
      shared routines.
      Signed-off-by: NPaul Ely <paul.ely@broadcom.com>
      Signed-off-by: NJames Smart <jsmart2021@gmail.com>
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      2a1160a0
  2. 10 1月, 2020 1 次提交
  3. 22 12月, 2019 1 次提交
    • J
      scsi: lpfc: Fix incomplete NVME discovery when target · be0709e4
      James Smart 提交于
      NVMe device re-discovery does not complete. Dev_loss_tmo messages seen on
      initiator after recovery from a link disturbance.
      
      The failing case is the following:
      
      When the driver (as a NVME target) receives a PLOGI, the driver initiates
      an "unreg rpi" mailbox command. While the mailbox command is in progress,
      the driver requests that an ACC be sent to the initiator. The target's ACC
      is received by the initiator and the initiator then transmits a PLOGI. The
      driver receives the PLOGI prior to receiving the completion for the PLOGI
      response WQE that sent the ACC. (Different delivery sources from the hw so
      the race is very possible). Given the PLOGI is prior to the ACC completion
      (signifying PLOGI exchange complete), the driver LS_RJT's the PRLI. The
      "unreg rpi" mailbox then completes. Since PRLI has been received, the
      driver transmits a PLOGI to restart discovery, which the initiator then
      ACC's.  If the driver processes the (re)PLOGI ACC prior to the completing
      the handling for the earlier ACC it sent the intiators original PLOGI,
      there is no state change for completion of the (re)PLOGI. The ndlp remains
      in "PLOGI Sent" and the initiator continues sending PRLI's which are
      rejected by the target until timeout or retry is reached.
      
      Fix by: When in target mode, defer sending an ACC for the received PLOGI
      until unreg RPI completes.
      
      Link: https://lore.kernel.org/r/20191218235808.31922-2-jsmart2021@gmail.comSigned-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <jsmart2021@gmail.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      be0709e4
  4. 06 11月, 2019 1 次提交
  5. 25 10月, 2019 1 次提交
  6. 23 10月, 2019 1 次提交
  7. 10 10月, 2019 1 次提交
  8. 01 10月, 2019 1 次提交
  9. 20 8月, 2019 5 次提交
  10. 09 4月, 2019 1 次提交
  11. 04 4月, 2019 3 次提交
  12. 06 2月, 2019 2 次提交
  13. 08 12月, 2018 2 次提交
    • J
      scsi: lpfc: Fix discovery failures during port failovers with lots of vports · dea16bda
      James Smart 提交于
      The driver is getting hit with 100s of RSCNs during remote port address
      changes. Each of those RSCN's ends up generating UNREG_RPI and REG_PRI
      mailbox commands.  The discovery engine within the driver doesn't wait for
      the mailbox command completions. Instead it sets state flags and moves
      forward. At some point, there's a massive backlog of mailbox commands which
      take time for the adapter to process. Additionally, it appears there were
      duplicate events from the switch so the driver generated duplicate mailbox
      commands for the same remote port.  During this window, failures on PLOGI
      and PRLI ELS's are see as the adapter is rejecting them as they are for
      remote ports that still have pending mailbox commands.
      
      Streamline the discovery engine so that PLOGI log checks for outstanding
      UNREG_RPIs and defer the processing until the commands complete. This
      better synchronizes the ELS transmission vs the RPI registrations.
      
      Filter out multiple UNREG_RPIs being queued up for the same remote port.
      
      Beef up log messages in this area.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <jsmart2021@gmail.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      dea16bda
    • J
      scsi: lpfc: refactor mailbox structure context fields · 3e1f0718
      James Smart 提交于
      The driver data structure for managing a mailbox command contained two
      context fields. Unfortunately, the context were considered "generic" to be
      used at the whim of the command code.  Of course, one section of code used
      fields this way, while another did it that way, and eventually there were
      mixups.
      
      Refactored the structure so that the generic contexts become a node context
      and a buffer context and all code standardizes on their use.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <jsmart2021@gmail.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      3e1f0718
  14. 07 11月, 2018 3 次提交
  15. 12 9月, 2018 1 次提交
  16. 03 8月, 2018 2 次提交
  17. 11 7月, 2018 1 次提交
  18. 29 5月, 2018 1 次提交
  19. 19 4月, 2018 1 次提交
  20. 13 3月, 2018 1 次提交
  21. 13 2月, 2018 2 次提交
  22. 21 12月, 2017 3 次提交
  23. 03 10月, 2017 1 次提交
  24. 25 8月, 2017 3 次提交