summaryrefslogtreecommitdiff
path: root/drivers/scsi/mpt3sas
AgeCommit message (Collapse)AuthorFilesLines
2021-03-25scsi: mpt3sas: Fix a typoBhaskar Chowdhury1-1/+1
s/encloure/enclosure/ Link: https://lore.kernel.org/r/20210322032145.2242520-1-unixbhaskar@gmail.com Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-19scsi: mpt3sas: Fix a few kernel-doc issuesLee Jones1-8/+10
Fixes the following W=1 kernel build warning(s): drivers/scsi/mpt3sas/mpt3sas_scsih.c:763: warning: Function parameter or member 'sas_address' not described in '__mpt3sas_get_sdev_by_addr' drivers/scsi/mpt3sas/mpt3sas_scsih.c:763: warning: expecting prototype for mpt3sas_get_sdev_by_addr(). Prototype was for __mpt3sas_get_sdev_by_addr() instead drivers/scsi/mpt3sas/mpt3sas_scsih.c:4535: warning: expecting prototype for _scsih_check_for_pending_internal_cmds(). Prototype was for mpt3sas_check_for_pending_internal_cmds() instead drivers/scsi/mpt3sas/mpt3sas_scsih.c:6188: warning: Function parameter or member 'port_entry' not described in '_scsih_look_and_get_matched_port_entry' drivers/scsi/mpt3sas/mpt3sas_scsih.c:6188: warning: Function parameter or member 'matched_port_entry' not described in '_scsih_look_and_get_matched_port_entry' drivers/scsi/mpt3sas/mpt3sas_scsih.c:6188: warning: Function parameter or member 'count' not described in '_scsih_look_and_get_matched_port_entry' drivers/scsi/mpt3sas/mpt3sas_scsih.c:6959: warning: Function parameter or member 'port' not described in 'mpt3sas_expander_remove' drivers/scsi/mpt3sas/mpt3sas_scsih.c:10494: warning: expecting prototype for mpt3sas_scsih_reset_handler(). Prototype was for mpt3sas_scsih_pre_reset_handler() instead drivers/scsi/mpt3sas/mpt3sas_scsih.c:10536: warning: expecting prototype for mpt3sas_scsih_reset_handler(). Prototype was for mpt3sas_scsih_reset_done_handler() instead drivers/scsi/mpt3sas/mpt3sas_scsih.c:12303: warning: expecting prototype for scsih__ncq_prio_supp(). Prototype was for scsih_ncq_prio_supp() instead Link: https://lore.kernel.org/r/20210317091230.2912389-15-lee.jones@linaro.org Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: MPT-FusionLinux.pdl@avagotech.com Cc: MPT-FusionLinux.pdl@broadcom.com Cc: linux-scsi@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-19scsi: mpt3sas: Update driver version to 37.101.00.00Suganath Prabu S1-2/+2
Update driver version to 37.101.00.00. Link: https://lore.kernel.org/r/20210305102904.7560-8-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-19scsi: mpt3sas: Force reply post array allocations to be within same 4 GB regionSuganath Prabu S1-16/+39
According to the MPI specification, reply post array buffers can not cross a 4 GB boundary. While allocating, if any buffer crosses the 4 GB boundary, then: - Release the already allocated memory pools; and - Reallocate them by changing the DMA coherent mask to 32-bit Link: https://lore.kernel.org/r/20210305102904.7560-7-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-19scsi: mpt3sas: Force reply post buffer allocations to be within same 4 GB regionSuganath Prabu S1-17/+42
According to the MPI specification, reply post buffers can not cross a 4 GB boundary. While allocating, if any buffer crosses the 4 GB boundary, then: - Release the already allocated memory pools; and - Reallocate them by changing the DMA coherent mask to 32-bit Link: https://lore.kernel.org/r/20210305102904.7560-6-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-19scsi: mpt3sas: Force reply buffer allocations to be within same 4 GB regionSuganath Prabu S1-23/+40
According to the MPI specification, reply buffers can not cross a 4 GB boundary. While allocating, if any buffer crosses the 4 GB boundary, then: - Release the already allocated memory pools; and - Reallocate them by changing the DMA coherent mask to 32-bit Link: https://lore.kernel.org/r/20210305102904.7560-5-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-19scsi: mpt3sas: Force sense buffer allocations to be within same 4 GB regionSuganath Prabu S1-46/+40
According to the MPI specification, sense buffers can not cross a 4 GB boundary. While allocating, if any buffer crosses the 4 GB boundary, then: - Release the already allocated memory pools; and - Reallocate them by changing the DMA coherent mask to 32-bit Link: https://lore.kernel.org/r/20210305102904.7560-4-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-19scsi: mpt3sas: Force chain buffer allocations to be within same 4 GB regionSuganath Prabu S1-26/+57
According to the MPI specification, chain buffers can not cross a 4 GB boundary. While allocating, if any buffer crosses the 4 GB boundary, then: - Release the already allocated memory pools; and - Reallocate them by changing the DMA coherent mask to 32-bit Link: https://lore.kernel.org/r/20210305102904.7560-3-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-17scsi: mpt3sas: Force PCIe scatterlist allocations to be within same 4 GB regionSuganath Prabu S2-47/+113
According to the MPI specification, PCIe SGL buffers can not cross a 4 GB boundary. While allocating, if any buffer crosses the 4 GB boundary, then: - Release the already allocated memory pools; and - Reallocate them by changing the DMA coherent mask to 32-bit Link: https://lore.kernel.org/r/20210305102904.7560-2-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-17scsi: mpt3sas: Replace unnecessary dynamic allocation with a static oneGustavo A. R. Silva2-17/+9
Dynamic memory allocation isn't actually needed and it can be replaced by statically allocating memory for struct object io_unit_pg3 with 36 hardcoded entries for its GPIOVal array. Also, this helps the with ongoing efforts to enable -Warray-bounds by fixing the following warning: drivers/scsi/mpt3sas/mpt3sas_ctl.c: In function ‘BRM_status_show’: drivers/scsi/mpt3sas/mpt3sas_ctl.c:3257:63: warning: array subscript 24 is above array bounds of ‘U16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds] 3257 | backup_rail_monitor_status = le16_to_cpu(io_unit_pg3->GPIOVal[24]); ./include/uapi/linux/byteorder/little_endian.h:36:51: note: in definition of macro ‘__le16_to_cpu’ 36 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x)) | ^ drivers/scsi/mpt3sas/mpt3sas_ctl.c:3257:31: note: in expansion of macro ‘le16_to_cpu’ 3257 | backup_rail_monitor_status = le16_to_cpu(io_unit_pg3->GPIOVal[24]); Link: https://github.com/KSPP/linux/issues/109 Link: https://lore.kernel.org/lkml/202103101058.16ED27BE3@keescook/ Link: https://lore.kernel.org/r/20210310235951.GA108661@embeddedor Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-16scsi: mpt3sas: Fix some kernel-doc misnaming issuesLee Jones1-8/+8
Fixes the following W=1 kernel build warning(s): drivers/scsi/mpt3sas/mpt3sas_ctl.c:463: warning: expecting prototype for mpt3sas_ctl_reset_handler(). Prototype was for mpt3sas_ctl_pre_reset_handler() instead drivers/scsi/mpt3sas/mpt3sas_ctl.c:495: warning: expecting prototype for mpt3sas_ctl_reset_handler(). Prototype was for mpt3sas_ctl_clear_outstanding_ioctls() instead drivers/scsi/mpt3sas/mpt3sas_ctl.c:512: warning: expecting prototype for mpt3sas_ctl_reset_handler(). Prototype was for mpt3sas_ctl_reset_done_handler() instead drivers/scsi/mpt3sas/mpt3sas_ctl.c:2771: warning: expecting prototype for _ ctl_ioctl_compat(). Prototype was for _ctl_ioctl_compat() instead drivers/scsi/mpt3sas/mpt3sas_ctl.c:2789: warning: expecting prototype for _ ctl_mpt2_ioctl_compat(). Prototype was for _ctl_mpt2_ioctl_compat() instead drivers/scsi/mpt3sas/mpt3sas_ctl.c:3061: warning: expecting prototype for sas_address_show(). Prototype was for host_sas_address_show() instead drivers/scsi/mpt3sas/mpt3sas_ctl.c:3682: warning: expecting prototype for diag_trigger_scsi_show(). Prototype was for diag_trigger_mpi_show() instead drivers/scsi/mpt3sas/mpt3sas_ctl.c:3941: warning: expecting prototype for sas_ncq_io_prio_show(). Prototype was for sas_ncq_prio_enable_show() instead Link: https://lore.kernel.org/r/20210312094738.2207817-10-lee.jones@linaro.org Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: MPT-FusionLinux.pdl@avagotech.com Cc: MPT-FusionLinux.pdl@broadcom.com Cc: linux-scsi@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-16scsi: mpt3sas: Fix a couple of misdocumented functions/paramsLee Jones1-3/+4
Fixes the following W=1 kernel build warning(s): drivers/scsi/mpt3sas/mpt3sas_transport.c:71: warning: Function parameter or member 'phy' not described in '_transport_get_port_id_by_sas_phy' drivers/scsi/mpt3sas/mpt3sas_transport.c:354: warning: Function parameter or member 'port_id' not described in '_transport_expander_report_manufacture' drivers/scsi/mpt3sas/mpt3sas_transport.c:354: warning: expecting prototype for transport_expander_report_manufacture(). Prototype was for _transport_expander_report_manufacture() instead drivers/scsi/mpt3sas/mpt3sas_transport.c:684: warning: Function parameter or member 'hba_port' not described in 'mpt3sas_transport_port_add' drivers/scsi/mpt3sas/mpt3sas_transport.c:684: warning: Excess function parameter 'port' description in 'mpt3sas_transport_port_add' Link: https://lore.kernel.org/r/20210312094738.2207817-7-lee.jones@linaro.org Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: MPT-FusionLinux.pdl@avagotech.com Cc: MPT-FusionLinux.pdl@broadcom.com Cc: linux-scsi@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-16scsi: mpt3sas: Fix a bunch of potential naming doc-rotLee Jones1-5/+5
Fixes the following W=1 kernel build warning(s): drivers/scsi/mpt3sas/mpt3sas_config.c:1795: warning: expecting prototype for mpt3sas_config_set_driver_trigger_pg0(). Prototype was for _config_set_driver_trigger_pg0() instead drivers/scsi/mpt3sas/mpt3sas_config.c:1929: warning: expecting prototype for mpt3sas_config_set_driver_trigger_pg1(). Prototype was for _config_set_driver_trigger_pg1() instead drivers/scsi/mpt3sas/mpt3sas_config.c:2080: warning: expecting prototype for mpt3sas_config_set_driver_trigger_pg2(). Prototype was for _config_set_driver_trigger_pg2() instead drivers/scsi/mpt3sas/mpt3sas_config.c:2240: warning: expecting prototype for mpt3sas_config_set_driver_trigger_pg3(). Prototype was for _config_set_driver_trigger_pg3() instead drivers/scsi/mpt3sas/mpt3sas_config.c:2397: warning: expecting prototype for mpt3sas_config_set_driver_trigger_pg4(). Prototype was for _config_set_driver_trigger_pg4() instead Link: https://lore.kernel.org/r/20210312094738.2207817-2-lee.jones@linaro.org Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: MPT-FusionLinux.pdl@avagotech.com Cc: MPT-FusionLinux.pdl@broadcom.com Cc: linux-scsi@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-16scsi: mpt3sas: Move a little data from the stack onto the heapLee Jones1-12/+26
Fixes the following W=1 kernel build warning(s): drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function ‘_scsih_scan_for_devices_after_reset’: drivers/scsi/mpt3sas/mpt3sas_scsih.c:10473:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] Link: https://lore.kernel.org/r/20210303144631.3175331-31-lee.jones@linaro.org Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: MPT-FusionLinux.pdl@avagotech.com Cc: MPT-FusionLinux.pdl@broadcom.com Cc: linux-scsi@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-16scsi: mpt3sas: Fix misspelling of _base_put_smid_default_atomic()Lee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/scsi/mpt3sas/mpt3sas_base.c:4185: warning: expecting prototype for _base_put_smid_default(). Prototype was for _base_put_smid_default_atomic() instead Link: https://lore.kernel.org/r/20210303144631.3175331-29-lee.jones@linaro.org Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: MPT-FusionLinux.pdl@avagotech.com Cc: MPT-FusionLinux.pdl@broadcom.com Cc: linux-scsi@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-05scsi: core: Replace sdev->device_busy with sbitmapMing Lei1-2/+1
SCSI currently uses an atomic variable to track queue depth for each attached device. The queue depth depends on many factors such as transport type and device implementation. In addition, the SCSI device queue depth is not a static entity but changes over time as a result of congestion management. While blk-mq currently tracks queue depth for each hctx, it can't easily be changed to accommodate the SCSI per-device requirement. The current approach of using an atomic variable doesn't scale well when there are lots of CPU cores and the disk is very fast. IOPS can be substantially impacted by the atomic in the hot path. Replace the atomic variable sdev->device_busy with an sbitmap for tracking the SCSI device queue depth. It has been observed that IOPS is improved ~30% by this patchset in the following test: 1) test machine(32 logical CPU cores) Thread(s) per core: 2 Core(s) per socket: 8 Socket(s): 2 NUMA node(s): 2 Model name: Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz 2) setup scsi_debug: modprobe scsi_debug virtual_gb=128 max_luns=1 submit_queues=32 delay=0 max_queue=256 3) fio script: fio --rw=randread --size=128G --direct=1 --ioengine=libaio --iodepth=2048 \ --numjobs=32 --bs=4k --group_reporting=1 --group_reporting=1 --runtime=60 \ --loops=10000 --name=job1 --filename=/dev/sdN [mkp: fix device_busy reference in mpt3sas] Link: https://lore.kernel.org/r/20210122023317.687987-14-ming.lei@redhat.com Link: https://lore.kernel.org/linux-block/20200119071432.18558-6-ming.lei@redhat.com/ Cc: Omar Sandoval <osandov@fb.com> Cc: Kashyap Desai <kashyap.desai@broadcom.com> Cc: Sumanesh Samanta <sumanesh.samanta@broadcom.com> Cc: Ewan D. Milne <emilne@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Tested-by: Sumanesh Samanta <sumanesh.samanta@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-05scsi: core: Add scsi_device_busy() wrapperMing Lei1-1/+1
Add scsi_device_busy() helper to prepare drivers for tracking device queue depth via sbitmap_queue. Link: https://lore.kernel.org/r/20210122023317.687987-12-ming.lei@redhat.com Cc: Omar Sandoval <osandov@fb.com> Cc: Kashyap Desai <kashyap.desai@broadcom.com> Cc: Sumanesh Samanta <sumanesh.samanta@broadcom.com> Cc: Ewan D. Milne <emilne@redhat.com> Tested-by: Sumanesh Samanta <sumanesh.samanta@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-02-09scsi: mpt3sas: Update driver version to 37.100.00.00Suganath Prabu S1-2/+2
Update driver version to 37.100.00.00. Link: https://lore.kernel.org/r/20210204033724.1345-3-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-02-09scsi: mpt3sas: Additional diagnostic buffer query interfaceSuganath Prabu S6-4/+177
When a host trace buffer is released, applications never know for what reason the buffer is released. Add a new IOCTL MPT3ADDNLDIAGQUERY to provide the trigger information due to which the diag buffer is released. Link: https://lore.kernel.org/r/20210204033724.1345-2-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-02-09scsi: mpt3sas: Add support for shared host tagset for CPU hotplugSreekanth Reddy3-18/+75
MPT Fusion adapters can steer completions to individual queues and we now have support for shared host-wide tags in the I/O stack. The addition of the host-wide tags allows us to enable multiqueue support for MPT Fusion adapters. Once host-wise tags are enabled, the CPU hotplug feature is also supported. Allow use of host-wide tags to be disabled through the "host_tagset_enable" module parameter. Once we do not have any major performance regressions using host-wide tags, we will drop the hand-crafted interrupt affinity settings. Performance is meeting expectations. About 3.1M IOPS using 24 Drive SSD on Aero controllers. Link: https://lore.kernel.org/r/20210202095832.23072-1-sreekanth.reddy@broadcom.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-02-09scsi: mpt3sas: Fix ReplyPostFree pool allocationSreekanth Reddy1-1/+2
Currently the driver allocates memory for ReplyPostFree queues in chunks of 16. In resource constrained environments--such as VM with 1 GB RAM and 2 CPUs--memory allocation for ReplyPostFree pools may fail because the driver tries to allocate a memory for 16 ReplyPostFree queues even though the actual number needed is 2. Change the driver to allocate memory for only the actual number of queues needed if the ReplyPostFree queue count is less than 16. Link: https://lore.kernel.org/r/20210201141522.25363-1-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-01-23scsi: mpt3sas: Simplify bool comparisonYANG LI1-2/+2
Fix the following coccicheck warning: ./drivers/scsi/mpt3sas/mpt3sas_base.c:2424:5-20: WARNING: Comparison of 0/1 to bool variable Link: https://lore.kernel.org/r/1610355253-25960-1-git-send-email-abaci-bugfix@linux.alibaba.com Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: YANG LI <abaci-bugfix@linux.alibaba.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-01-06scsi: mpt3sas: Fix spelling mistake in Kconfig "compatiblity" -> "compatibility"Colin Ian King1-1/+1
There is a spelling mistake in the Kconfig help text. Fix it. Link: https://lore.kernel.org/r/20201217172019.57768-1-colin.king@canonical.com Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-01-01Merge tag 'scsi-fixes' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is a load of driver fixes (12 ufs, 1 mpt3sas, 1 cxgbi). The big core two fixes are for power management ("block: Do not accept any requests while suspended" and "block: Fix a race in the runtime power management code") which finally sorts out the resume problems we've occasionally been having. To make the resume fix, there are seven necessary precursors which effectively renames REQ_PREEMPT to REQ_PM, so every "special" request in block is automatically a power management exempt one. All of the non-PM preempt cases are removed except for the one in the SCSI Parallel Interface (spi) domain validation which is a genuine case where we have to run requests at high priority to validate the bus so this becomes an autopm get/put protected request" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (22 commits) scsi: cxgb4i: Fix TLS dependency scsi: ufs: Un-inline ufshcd_vops_device_reset function scsi: ufs: Re-enable WriteBooster after device reset scsi: ufs-mediatek: Use correct path to fix compile error scsi: mpt3sas: Signedness bug in _base_get_diag_triggers() scsi: block: Do not accept any requests while suspended scsi: block: Remove RQF_PREEMPT and BLK_MQ_REQ_PREEMPT scsi: core: Only process PM requests if rpm_status != RPM_ACTIVE scsi: scsi_transport_spi: Set RQF_PM for domain validation commands scsi: ide: Mark power management requests with RQF_PM instead of RQF_PREEMPT scsi: ide: Do not set the RQF_PREEMPT flag for sense requests scsi: block: Introduce BLK_MQ_REQ_PM scsi: block: Fix a race in the runtime power management code scsi: ufs-pci: Enable UFSHCD_CAP_RPM_AUTOSUSPEND for Intel controllers scsi: ufs-pci: Fix recovery from hibernate exit errors for Intel controllers scsi: ufs-pci: Ensure UFS device is in PowerDown mode for suspend-to-disk ->poweroff() scsi: ufs-pci: Fix restore from S4 for Intel controllers scsi: ufs-mediatek: Keep VCC always-on for specific devices scsi: ufs: Allow regulators being always-on scsi: ufs: Clear UAC for RPMB after ufshcd resets ...
2020-12-17Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds7-233/+2806
Pull SCSI updates from James Bottomley: "This consists of the usual driver updates (ufs, qla2xxx, smartpqi, target, zfcp, fnic, mpt3sas, ibmvfc) plus a load of cleanups, a major power management rework and a load of assorted minor updates. There are a few core updates (formatting fixes being the big one) but nothing major this cycle" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (279 commits) scsi: mpt3sas: Update driver version to 36.100.00.00 scsi: mpt3sas: Handle trigger page after firmware update scsi: mpt3sas: Add persistent MPI trigger page scsi: mpt3sas: Add persistent SCSI sense trigger page scsi: mpt3sas: Add persistent Event trigger page scsi: mpt3sas: Add persistent Master trigger page scsi: mpt3sas: Add persistent trigger pages support scsi: mpt3sas: Sync time periodically between driver and firmware scsi: qla2xxx: Update version to 10.02.00.104-k scsi: qla2xxx: Fix device loss on 4G and older HBAs scsi: qla2xxx: If fcport is undergoing deletion complete I/O with retry scsi: qla2xxx: Fix the call trace for flush workqueue scsi: qla2xxx: Fix flash update in 28XX adapters on big endian machines scsi: qla2xxx: Handle aborts correctly for port undergoing deletion scsi: qla2xxx: Fix N2N and NVMe connect retry failure scsi: qla2xxx: Fix FW initialization error on big endian machines scsi: qla2xxx: Fix crash during driver load on big endian machines scsi: qla2xxx: Fix compilation issue in PPC systems scsi: qla2xxx: Don't check for fw_started while posting NVMe command scsi: qla2xxx: Tear down session if FW say it is down ...
2020-12-09scsi: mpt3sas: Signedness bug in _base_get_diag_triggers()Dan Carpenter1-1/+1
The "trigger_flags" variable needs to be signed for the error checking to work. Link: https://lore.kernel.org/r/X9DZH37bYPHwSQRP@mwanda Fixes: aec93e8e2385 ("scsi: mpt3sas: Add persistent trigger pages support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09scsi: mpt3sas: Update driver version to 36.100.00.00Suganath Prabu S1-3/+3
Update driver version to 36.100.00.00 Link: https://lore.kernel.org/r/20201126094311.8686-9-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09scsi: mpt3sas: Handle trigger page after firmware updateSuganath Prabu S1-1/+49
If a firmware update adds support for the trigger pages, then the driver should handle this by writing the existing trigger data from the driver's internal data structure to the corresponding trigger pages in NVRAM. Also handle the case where the trigger page capability is no longer present after a firmware downgrade. Link: https://lore.kernel.org/r/20201126094311.8686-8-suganath-prabu.subramani@broadcom.com Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09scsi: mpt3sas: Add persistent MPI trigger pageSuganath Prabu S3-1/+224
This page is used to store information about MPI (IOC Status & LogInfo) triggers. Driver Persistent Trigger Page-4 format: ------------------------------------------------------- | 31 24 23 16 15 8 7 0| Byte ------------------------------------------------------- | PageType | PageNumber | Reserved | PageVersion | 0x00 -------------------------------------------------------- | Reserved | ExtPageType | ExtPageLength | 0x04 -------------------------------------------------------- | Reserved | NumMpiTriggerEntries | 0x08 -------------------------------------------------------- | MPITriggerEntry[0] | 0x0C -------------------------------------------------------- | … | -------------------------------------------------------- | MPITriggerEntry[19] | 0xA4 -------------------------------------------------------- NumMpiTriggerEntries: This field indicates number of MPI (IOC Status & LogInfo) trigger entries stored in this page. Currently driver is supporting a maximum of 20-MPI trigger entries. MPITriggerEntry: ----------------------------------------------------- | 31 16 15 0 | ----------------------------------------------------- | Reserved | IOCStatus | ----------------------------------------------------- | IOCLogInfo | ----------------------------------------------------- IOCStatus => Status value from the IOC IOCLogInfo => Specific value that supplements the IOCStatus. Link: https://lore.kernel.org/r/20201126094311.8686-7-suganath-prabu.subramani@broadcom.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09scsi: mpt3sas: Add persistent SCSI sense trigger pageSuganath Prabu S3-0/+222
Trigger Page3 is used to store information about SCSI Sense triggers: Persistent Trigger Page-3 ------------------------------------------------------------------ | 31 24 23 16 15 8 7 0| Byte ------------------------------------------------------------------ | PageType | PageNumber | Reserved | PageVersion | 0x00 ------------------------------------------------------------------ | Reserved | ExtPageType | ExtPageLen | 0x04 ------------------------------------------------------------------ | Reserved | NumScsiSense | TriggerEntries | 0x08 ------------------------------------------------------------------ | ScsiSenseTriggerEntry[0] | 0x0C ------------------------------------------------------------------ | … … | ------------------------------------------------------------------ | ScsiSenseTriggerEntry[19] | 0x58 ------------------------------------------------------------------ NumScsiSenseTriggerEntries: This field indicates number of SCSI Sense trigger entries stored in this page. Currently driver is supporting a maximum of 20-SCSI Sense trigger entries. ScsiSenseTriggerEntry: ----------------------------------------------- | 31 24 23 16 15 8 7 0 | ----------------------------------------------- | Reserved | SenseKey | ASC | ASCQ | ----------------------------------------------- ASCQ => Additional Sense Code Qualifier ASC => Additional Sense Code SenseKey => Sense Key values ASCQ => Additional Sense Code Qualifier ASC => Additional Sense Code SenseKey => Sense Key values Link: https://lore.kernel.org/r/20201126094311.8686-6-suganath-prabu.subramani@broadcom.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09scsi: ufs: Remove unused macro definition POWER_DESC_MAX_SIZEBean Huo0-0/+0
POWER_DESC_MAX_SIZE is unused, remove it. Link: https://lore.kernel.org/r/20201207190137.6858-2-huobean@gmail.com Acked-by: Avri Altman <avri.altman@wdc.com> Acked-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09scsi: mpt3sas: Add persistent Event trigger pageSuganath Prabu S3-0/+226
Trigger Page2 is used to store information about Event triggers: 31 24 23 16 15 8 7 0 Byte ----------------------------------------------- |PageType |PageNumber |Reserved |PageVersion| 0x00 ----------------------------------------------- |Reserved |ExtPageType | ExtPageLength | 0x04 ----------------------------------------------- | Reserved | NumMPIEventTriggers | 0x08 ----------------------------------------------- | MPIEventTriggerEntries | 0x0C | | 0xFC ----------------------------------------------- Number of MPI Event Trigger Entries currently stored in this page. If this is set to zero, there are no valid MPI-Event-Trigger entries available in this page. MPIEventTriggerEntry: - MPIEventCode [15:00] MPI Event code specified in MPI-Spec - MPIEventCodeSpecific [16:31] For Event Code “MPI2_EVENT_LOG_ENTRY_ADDED (0x0021)”, this field specifies the Log-Entry-Qualifier. For all other Event Codes, this field is reserved and not used Maximum of 20-event trigger entries can be stored in this page. Link: https://lore.kernel.org/r/20201126094311.8686-5-suganath-prabu.subramani@broadcom.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09scsi: mpt3sas: Add persistent Master trigger pageSuganath Prabu S3-0/+203
Trigger Page 1 is used to store information about Master triggers. Below are the Master trigger conditions: Bit[3] Trigger condition for Device Removal event Bit[2] Trigger condition for TM command issued by driver Bit[1] Trigger condition for Adapter reset issued by driver Bit[0] Trigger condition for IOC Fault state During driver load, if Master trigger type bit is enabled in the Persistent Trigger Page0, then read the Persistent Trigger Page1 and update the IOC instance's diag_trigger_master.MasterData with Persistent Trigger Page1's MasterTriggerFlags. Link: https://lore.kernel.org/r/20201126094311.8686-4-suganath-prabu.subramani@broadcom.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09scsi: mpt3sas: Add persistent trigger pages supportSuganath Prabu S4-0/+303
The user can set trigger values in order to collect the IOC's host trace buffer automatically upon detecting certain conditions. However, the trigger values that the user sets are not persistent across system reboot or reload of the driver. In order to make the user trigger settings persistent, these trigger values need to be saved in the IOC's NVRAM pages: - Driver Persistent Trigger Page 0: This page is used to store list of trigger types that are enabled - Driver Persistent Trigger Page 1: This page stores the list of Master triggers that are enabled - Driver Persistent Trigger Page 2: This page stores the list of MPI Event Triggers that are enabled - Driver Persistent Trigger Page 3: This page stores the list of SCSI Sense Triggers that are enabled - Driver Persistent Trigger Page 4: This page stores the list of IOCStatus-LogInfo Triggers that are enabled. Whenever user configures triggers, the driver persists the values in the corresponding trigger pages. When the driver is subsequently reloaded, the driver reads the values from the trigger pages and configures the triggers accordingly. During firmware upload operation, if the newer firmware supports the trigger page feature, then driver persists the configured diag trigger values to NVRAM. Link: https://lore.kernel.org/r/20201126094311.8686-3-suganath-prabu.subramani@broadcom.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09scsi: mpt3sas: Sync time periodically between driver and firmwareSuganath Prabu S2-3/+104
The controller time currently gets updated with host time during driver load or when a controller reset is issued. I.e. when host issues the IOCInit request message to the HBA firmware. This IOCInit message has a field named 'TimeStamp' with which the host updates the controller time. Sometimes controller time drifts with respect to the host and it is difficult to correlate host logs with controller logs. Issuing a controller reset to sync the time would impact in-flight I/O and is not a viable option. Instead the driver now sends an IO_UNIT_CONTROL Request to sync the time periodically. This is done from the watchdog thread which gets invoked every second. The time synchronization interval is specified in the 'TimeSyncInterval' field in Manufacturing Page11 by the controller: TimeSyncInterval - 8 bits bits 0-6: Time stamp Synchronization interval value bit 7: Time stamp Synchronization interval unit, (if this bit is one then Timestamp Synchronization interval value is specified in terms of hours else Timestamp Synchronization interval value is specified in terms of minutes). The driver keeps track of the timer using IOC's timestamp_update_count field. This field value gets incremented whenever the watchdog thread gets invoked. And whenever this field value is greater than or equal to the Time Stamp Synchronization interval value, the driver sends the IO_UNIT_CONTROL Request message to controller to update the time and then it resets the timestamp_update_count field to zero. Link: https://lore.kernel.org/r/20201126094311.8686-2-suganath-prabu.subramani@broadcom.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-01scsi: mpt3sas: Increase IOCInit request timeout to 30sSreekanth Reddy1-1/+1
Currently the IOCInit request message timeout is set to 10s. This is not sufficient in some scenarios such as during HBA FW downgrade operations. Increase the IOCInit request timeout to 30s. Link: https://lore.kernel.org/r/20201130082733.26120-1-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-01scsi: mpt3sas: Fix ioctl timeoutSuganath Prabu S1-1/+1
Commit c1a6c5ac4278 ("scsi: mpt3sas: For NVME device, issue a protocol level reset") modified the ioctl path 'timeout' variable type to u8 from unsigned long, limiting the maximum timeout value that the driver can support to 255 seconds. If the management application is requesting a higher value the resulting timeout will be zero. The operation times out immediately and the ioctl request fails. Change datatype back to unsigned long. Link: https://lore.kernel.org/r/20201125094838.4340-1-suganath-prabu.subramani@broadcom.com Fixes: c1a6c5ac4278 ("scsi: mpt3sas: For NVME device, issue a protocol level reset") Cc: <stable@vger.kernel.org> #v4.18+ Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-01scsi: mpt3sas: Remove in_interrupt()Ahmed S. Darwish1-1/+3
_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: Daniel Wagner <dwagner@suse.de> Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-26scsi: mpt3sas_scsih: Use generic power managementVaibhav Gupta1-21/+13
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-17-vaibhavgupta40@gmail.com Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-26scsi: mpt3sas_scsih: Drop PCI Wakeup calls from .resumeVaibhav Gupta1-1/+0
The driver calls pci_enable_wake(...., false) in scsih_resume(), and there is no corresponding pci_enable_wake(...., true) in scsih_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from scsih_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-16-vaibhavgupta40@gmail.com Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-11scsi: mpt3sas: mpt3sas_scsih: Fix function documentation formattingLee Jones1-4/+4
Fixes the following W=1 kernel build warning(s): drivers/scsi/mpt3sas/mpt3sas_scsih.c:2778: warning: Function parameter or member 'ioc' not described in 'scsih_tm_cmd_map_status' drivers/scsi/mpt3sas/mpt3sas_scsih.c:2778: warning: Function parameter or member 'channel' not described in 'scsih_tm_cmd_map_status' drivers/scsi/mpt3sas/mpt3sas_scsih.c:2829: warning: Function parameter or member 'ioc' not described in 'scsih_tm_post_processing' drivers/scsi/mpt3sas/mpt3sas_scsih.c:2829: warning: Function parameter or member 'channel' not described in 'scsih_tm_post_processing' Link: https://lore.kernel.org/r/20201102142359.561122-3-lee.jones@linaro.org 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@avagotech.com Cc: MPT-FusionLinux.pdl@broadcom.com Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-05scsi: mpt3sas: Bump driver version to 35.101.00.00Sreekanth Reddy1-2/+2
Bump mpt3sas driver version to 35.101.00.00 Link: https://lore.kernel.org/r/20201027130847.9962-15-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-05scsi: mpt3sas: Add module parameter multipath_on_hbaSreekanth Reddy4-7/+76
Add module parameter multipath_on_hba to enable/disable multi-port path topology support. By default this feature is enabled on SAS3.5 HBA device and disabled on SAS3 &SAS2.5 HBA devices. When this feature is disabled then driver uses a default PhysicalPort(PortID) number i.e. 255 instead of the PhysicalPort number provided by HBA firmware. Link: https://lore.kernel.org/r/20201027130847.9962-14-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-05scsi: mpt3sas: Handle vSES vphy object during HBA resetSreekanth Reddy1-0/+233
During HBA reset the Port ID of vSES device may change. As a result, it is necessary to refresh virtual_phy objects after reset. Each Port's vphy_list table needs to be updated after updating the HBA port table. The algorithm is as follows: - Loop over each port entry from HBA port table * Loop over each virtual phy entry from port's vphys_list table - Mark virtual phy entry as dirty by setting dirty bit in virtual phy entry's flags field - Read SASIOUnitPage0 page - Loop over each HBA Phy's Phy data from SASIOUnitPage0 * If phy's remote attached device is not SES device then continue with processing next HBA Phy's Phy data; * Read SASPhyPage0 data for this Phy number and determine whether current phy is a virtual phy or not. If it is not a virtual phy then continue with next Phy data; * Get the current phy's remote attached vSES device's SAS Address; * Loop over each port entry from HBA port table - If Port's vphys_mask field is zero then continue with next Port entry, - Loop over each virtual phy entry from Port's vphy_list table - If the current phy's remote SAS Address is different from virtual phy entry's SAS Address then continue with next virtual phy entry, - Set bit corresponding to current phy number in virtual phy entry's phy_mask field, - Get the HBA port table's Port entry corresponding to Phy data's 'Port' value, * If there is no Port entry corresponding to Phy data's 'Port' value in HBA port table then create a new port entry and add it to HBA port table. - If this retrieved Port entry is the same as the current Port entry then don't do anything, just clear the dirty bit from virtual phy entry's flag field and continue with processing next HBA Phy's Phy data. - If this retrieved Port entry is different from the current Port entry then move the current virtual phy entry from current Port's vphys_list to retrieved Port entry's vphys_list. * Clear current phy bit in current Port entry's vphys_mask and set the current phy bit in the retrieved Port entry's vphys_mask field. * Clear the dirty bit from virtual phy entry's flag field and continue with next HBA Phy's Phy data. - Delete the 'virtual phy' entries and HBA's 'Port table' entries which are still marked as 'dirty'. Link: https://lore.kernel.org/r/20201027130847.9962-13-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-05scsi: mpt3sas: Add bypass_dirty_port_flag parameterSreekanth Reddy3-30/+44
Added a new parameter bypass_dirty_port_flag in function mpt3sas_get_port_by_id(). When this parameter is set to one then search for matching hba port entry from port_table_list even when this hba_port entry is marked as dirty. Link: https://lore.kernel.org/r/20201027130847.9962-12-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-05scsi: mpt3sas: Handling HBA vSES deviceSreekanth Reddy3-11/+198
Each direct attached device will have a unique Port ID, but with an exception. HBA vSES may use the same Port ID of another direct attached device Port's ID. As a result, special handling is needed for vSES. Create a virtual_phy object when a new HBA vSES device is detected and add this virtual_phy object to vphys_list of port ID's hba_port object. When the HBA vSES device is removed then remove the corresponding virtual_phy object from its parent's hba_port's vphy_list and free this virtual_vphy object. In hba_port object add vphy_mask field to hold the list of HBA phy bits which are assigned to vSES devices. Also add vphy_list list to hold list of virtual_phy objects which holds the same portID of current hba_port's portID. Also, add a hba_vphy field in _sas_phy object to determine whether this _sas_phy object belongs to vSES device or not. - Allocate a virtual_phy object whenever a virtual phy is detected while processing the SASIOUnitPage0's phy data. And this allocated virtual_phy object to corresponding PortID's hba_port's vphy_list. - When a vSES device is added to the SML then initialize the corresponding virtual_phy objects's sas_address field with vSES device's SAS Address. - Free this virtual_phy object during driver unload time and when this vSES device is removed. Link: https://lore.kernel.org/r/20201027130847.9962-11-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-05scsi: mpt3sas: Set valid PhysicalPort in SMPPassThroughSreekanth Reddy3-6/+72
The driver currently sets PhysicalPort field to 0xFF for SMPPassthrough Request message. In zoning topologies this SMPPassthrough command always operates on devices in one zone (default zone) even when user issues SMP command for other zone drives. Define _transport_get_port_id_by_rphy() and _transport_get_port_id_by_sas_phy() helper functions to get Physical Port number from sas_rphy & sas_phy respectively for SMPPassthrough request message so that SMP Passthrough request message is sent to intended zone device. Link: https://lore.kernel.org/r/20201027130847.9962-10-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-05scsi: mpt3sas: Update hba_port objects after host resetSreekanth Reddy1-0/+338
During host reset there is a chance that the Port number allocated by the firmware for the attached devices may change. Also, it may be possible that some HBA phy's can go down/come up after reset. As a result, the driver can't just trust the HBA Port table that it has populated before host reset as valid. Instead it has to update the HBA Port table in such a way that it shouldn't disturb the drives which are still accessible even after host reset. Use the following algorithm to update the HBA Port table during host reset: I. After host reset operation and before marking the devices as responding/non-responding, create a temporary Port table called "New Port table" by parsing each of the HBA phy's Phy data info read from SAS IOUnit Page0: a. Check whether Phy's negotiated link rate is greater than 1.5Gbps, if not go to next Phy; b. Get the SAS Address of the attached device; c. Create a new entry in the "New Port table" with SAS Address field filled with attached device's SAS Address, port number with Phy's Port number (read from SAS IOUnit Page0) and enable bit in the 'Phy mask' field corresponding to current Phy number. New entry is created only if the driver can't find an entry in the "New Port table" which matches with attached device 'SAS Address' & 'Port Number'. If it finds an entry with matches with attached device 'SAS Address' & 'Port Number' then the driver takes that matched entry and will enable current Phy number bit in the 'Phy mask' field; d. After parsing all the HBA phy's info, the driver will have complete Port table info in "New Port table". II. Mark all the existing sas_device & sas_expander device structures as 'dirty'. III. Mark each entry of the HBA Port lists as 'dirty'. IV. Take each entry from 'New Port table' one by one and check whether the entry has any corresponding matched entry (which is marked as 'dirty') in the HBA Port table or not. While looking for a corresponding matched entry, look for matched entry in the sequence from top row to bottom row listed in the following table. If you find any matched entry (according to any of the rules tabulated below) then perform the action mentioned in the 'Action' column in that matched rule. =========================================================================== |Search |SAS | Phy Mask | Port | Possibilities| Action | |every |Address | or | Number | | required | |entry |matched?| subset of| matched?| | | |in below| | phy mask | | | | |sequence| | matched? | | | | =========================================================================== | 1 |matched | matched | matched | nothing |* unmark HBA port | | | | | | changed |table entry as | | | | | | |dirty | --------------------------------------------------------------------------- | 2 |matched | matched | not | port number |* Update port | | | | | matched | is changed |number in the | | | | | | |matched port table | | | | | | |entry | | | | | | |* unmask HBA port | | | | | | |table entry as | | | | | | |dirty | --------------------------------------------------------------------------- | 3.a |matched | subset of| matched |some phys |* Add these new | | | | phy mask | (or) |might have |phys to current | | | | matched | not |enabled which |port in STL | | | | | matched |are previously|* Update phy mask | | | | | (but |disabled |field in HBA's port| | | | | first | |table's matched | | | | | look for| |entry, | | | | | matched | |* Update port | | | | | one) | |number in the | | | | | | |matched port | | | | | | |table entry (if | | | | | | |port number is | | | | | | |changed), | | | | | | |* Unmask HBA port | | | | | | |table entry as | | | | | | |dirty | --------------------------------------------------------------------------- | 3.b |matched | subset of| matched |some phys |*Remove these phys | | | | phy mask | (or) |might have |from current port | | | | matched | not |disabled which|in STL | | | | | matched |are previously|* Update phy mask | | | | | (but |enabled |field in HBA's port| | | | | first | |tables's matched | | | | | look for| |entry, | | | | | matched | |*Update port number| | | | | one) | |in the matched port| | | | | | |table entry (if | | | | | | |port number is | | | | | | |changed), | | | | | | |* Unmask HBA port | | | | | | |table entry as | | | | | | |dirty | --------------------------------------------------------------------------- | 4 |matched | not | matched |A cable |*Remove old phys & | | | | matched | (or) |attached to an|new phys to current| | | | | not |expander is |port in STL | | | | | matched |changed to |* Update phy mask | | | | | |another HBA |field in HBA's port| | | | | |port during |tables's matched | | | | | |reset |entry, | | | | | | |*Update port number| | | | | | |in the matched port| | | | | | |table entry (if | | | | | | |port number is | | | | | | |changed), | | | | | | |* Unmask HBA port | | | | | | |table entry as | | | | | | |dirty | --------------------------------------------------------------------------- V. Delete the hba_port objects which are still marked as dirty. Link: https://lore.kernel.org/r/20201027130847.9962-9-sreekanth.reddy@broadcom.com Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-05scsi: mpt3sas: Get sas_device objects using device's rphySreekanth Reddy3-6/+47
In the following scsi_host_template and sas_function_template callback functions the driver does not have PhysicalPort number information to retrieve the sas_device object using SAS Address & PhysicalPort number. In these callback functions the device's rphy object is used to retrieve sas_device object for the device. .target_alloc, .get_enclosure_identifier .get_bay_identifier When a rphy (of type sas_rphy) object is allocated then its address is saved in corresponding sas_device object's rphy field. In __mpt3sas_get_sdev_by_rphy(), the driver loops over all the sas_device objects from sas_device_list list to retrieve the sas_device objects whose rphy matches the provided rphy. Link: https://lore.kernel.org/r/20201027130847.9962-8-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-11-05scsi: mpt3sas: Rename transport_del_phy_from_an_existing_port()Sreekanth Reddy2-12/+30
Renamed _transport_add_phy_to_an_existing_port() to mpt3sas_transport_add_phy_to_an_existing_port() and _transport_del_phy_from_an_existing_port() to mpt3sas_transport_del_phy_from_an_existing_port() as the driver needs to call these functions from outside mpt3sas_transport.c file. Added extra function argument 'port' of type struct hba_port to above functions and check for portID before adding/removing the phy from the _sas_port object. I.e. add/remove the phy from _sas_port object only if _sas_port's port object and phy's port object are the same. Link: https://lore.kernel.org/r/20201027130847.9962-7-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-02-20 23:16:36 +0300