- 20 May, 2022 22 commits
-
-
Bart Van Assche authored
Split the drivers/scsi/ufs directory into 'core' and 'host' directories under the drivers/ufs/ directory. Move shared header files into the include/ufs/ directory. This separation makes it clear which header files UFS drivers are allowed to include (include/ufs/*.h) and which header files UFS drivers are not allowed to include (drivers/ufs/core/*.h). Update the MAINTAINERS file. Add myself as a UFS reviewer. Link: https://lore.kernel.org/r/20220511212552.655341-1-bvanassche@acm.org Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Avri Altman <avri.altman@wdc.com> Cc: Bean Huo <beanhuo@micron.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Keoseong Park <keosung.park@samsung.com> Tested-by:
Bean Huo <beanhuo@micron.com> Tested-by:
Adrian Hunter <adrian.hunter@intel.com> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Acked-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Colin Ian King authored
Variable toke is being assigned a value that is never read. The variable is redundant, remove it. Cleans up clang scan build warning: warning: Although the value stored to 'toke' is used in the enclosing expression, the value is never actually read from 'toke' [deadcode.DeadStores] Link: https://lore.kernel.org/r/20220518102103.514701-1-colin.i.king@gmail.comSigned-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
James Smart authored
Modify the NVMe I/O path to look for VMID support and call the transport to obtain the I/O's appid value. Link: https://lore.kernel.org/r/20220519123110.17361-5-jsmart2021@gmail.comReviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Co-developed-by:
Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
James Smart authored
Rework lpfc_vmid_get_appid() arguments to remove scsi_cmnd dependency. The function is now callable by the NVMe I/O path. Fix up SCSI call path to accommodate the arg change. Link: https://lore.kernel.org/r/20220519123110.17361-4-jsmart2021@gmail.comReviewed-by:
-
James Smart authored
Remove VMID code from its SCSI-specific location and move to a new file solely for VMID code. Link: https://lore.kernel.org/r/20220519123110.17361-3-jsmart2021@gmail.comReviewed-by:
-
Muneendra Kumar authored
Add nvme_fc_io_getuuid() to the nvme-fc transport. The routine is invoked by the FC LLDD on a per-I/O request basis. The routine translates from the FC-specific request structure to the bio and the cgroup structure in order to obtain the FC appid stored in the cgroup structure. If a value is not set or a bio is not found, a NULL appid (aka uuid) will be returned to the LLDD. Link: https://lore.kernel.org/r/20220519123110.17361-2-jsmart2021@gmail.comReviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by:
-
Bodo Stroesser authored
In tcmu_blocks_release(), lock_page() is called to prevent a race causing possible data corruption. Since lock_page() might sleep, calling it while holding XArray lock is a bug. To fix this, replace the xas_for_each() call with xa_for_each_range(). Since the latter does its own handling of XArray locking, the xas_lock() and xas_unlock() calls around the original loop are no longer necessary. The switch to xa_for_each_range() slows down the loop slightly. This is acceptable since tcmu_blocks_release() is not relevant for performance. Link: https://lore.kernel.org/r/20220517192913.21405-1-bostroesser@gmail.com Fixes: bb9b9eb0 ("scsi: target: tcmu: Fix possible data corruption") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Bodo Stroesser <bostroesser@gmail.com> Signed-off-by:
-
Haowen Bai authored
container_of() will never return NULL. Link: https://lore.kernel.org/r/1652750737-22673-1-git-send-email-baihaowen@meizu.comSigned-off-by:
Haowen Bai <baihaowen@meizu.com> Signed-off-by:
-
Haowen Bai authored
adpt_post_wait_lock was declared and initialized by DEFINE_SPINLOCK so we don't need to call spin_lock_init(). Drop the call. Link: https://lore.kernel.org/r/1652176024-3981-1-git-send-email-baihaowen@meizu.comSigned-off-by:
-
Colin Ian King authored
The variable 'op' is assigned a value and is never read. The variable is not used and is redundant, remove it. Link: https://lore.kernel.org/r/20220517092518.93159-1-colin.i.king@gmail.comSigned-off-by:
-
John Garry authored
The memories for the slot should be observed to be written prior to observing the slot as ready. Prior to commit 26fc0ea7 ("scsi: libsas: Drop SAS_TASK_AT_INITIATOR"), we had a spin_lock() + spin_unlock() immediately before marking the slot as ready. The spin_unlock() - with release semantics - caused the slot memory to be observed to be written. Now that the spin_lock() + spin_unlock() is gone, use a smp_wmb(). Link: https://lore.kernel.org/r/1652774661-12935-1-git-send-email-john.garry@huawei.com Fixes: 26fc0ea7 ("scsi: libsas: Drop SAS_TASK_AT_INITIATOR") Reported-by:
Yihang Li <liyihang6@hisilicon.com> Tested-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Karan Tilak Kumar authored
Cisco VIC supports only 47 bits. If the host sends DMA addresses that are greater than 47 bits, it causes work queue (WQ) errors in the VIC. Link: https://lore.kernel.org/r/20220513205605.81788-1-kartilak@cisco.comTested-by:
Karan Tilak Kumar <kartilak@cisco.com> Co-developed-by:
Dhanraj Jhawar <djhawar@cisco.com> Signed-off-by:
Sesidhar Baddela <sebaddel@cisco.com> Signed-off-by:
Arulprabhu Ponnusamy <arulponn@cisco.com> Signed-off-by:
-
Sreekanth Reddy authored
Add sysfs attributes for exposing target device details such as SAS address, firmware device handle, and persistent ID for the controller-attached devices and RAID volumes. Link: https://lore.kernel.org/r/20220517115310.13062-3-sreekanth.reddy@broadcom.comReviewed-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
Add shost related sysfs attributes to display the controller's firmware version, queue depth, number of requests, and number of reply queues. Also add an attribute to set & get the logging_level. Link: https://lore.kernel.org/r/20220517115310.13062-2-sreekanth.reddy@broadcom.comReviewed-by:
-
Harshit Mogalapalli authored
As memset() of bmbx is immediately followed by a memcpy() where bmbx is the destination, the memset() is redundant. Link: https://lore.kernel.org/r/20220505143703.45441-1-harshit.m.mogalapalli@oracle.comSigned-off-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Signed-off-by:
-
Harshit Mogalapalli authored
As memset() of scmd->sense_buffer is immediately followed by a memcpy() where scmd->sense_buffer is the destination. The memset() is redundant. Link: https://lore.kernel.org/r/20220505143214.44908-1-harshit.m.mogalapalli@oracle.comSigned-off-by:
-
Dan Carpenter authored
Return -ENOMEM instead of success if dma_alloc_coherent() fails. Link: https://lore.kernel.org/r/YnOmMGHqCOtUCYQ1@kili Fixes: 43ca1100 ("scsi: mpi3mr: Add support for PEL commands") Signed-off-by:
-
John Garry authored
Removing an ATA device via sysfs means that the device may not be found through re-scanning: root@ubuntu:/home/john# lsscsi [0:0:0:0] disk SanDisk LT0200MO P404 /dev/sda [0:0:1:0] disk ATA HGST HUS724040AL A8B0 /dev/sdb [0:0:8:0] enclosu 12G SAS Expander RevB - root@ubuntu:/home/john# echo 1 > /sys/block/sdb/device/delete root@ubuntu:/home/john# echo "- - -" > /sys/class/scsi_host/host0/scan root@ubuntu:/home/john# lsscsi [0:0:0:0] disk SanDisk LT0200MO P404 /dev/sda [0:0:8:0] enclosu 12G SAS Expander RevB - root@ubuntu:/home/john# The problem is that the rescan of the device may conflict with the device in being re-initialized, as follows: - In the rescan we call hisi_sas_slave_alloc() in store_scan() -> sas_user_scan() -> [__]scsi_scan_target() -> scsi_probe_and_add_lunc() -> scsi_alloc_sdev() -> hisi_sas_slave_alloc() -> hisi_sas_init_device() In hisi_sas_init_device() we issue an IT nexus reset for ATA devices - That IT nexus causes the remote PHY to go down and this triggers a bcast event - In parallel libsas processes the bcast event, finds that the phy is down and marks the device as gone The hard reset issued in hisi_sas_init_device() is unncessary - as described in the code comment - so remove it. Also set dev status as HISI_SAS_DEV_NORMAL as the hisi_sas_init_device() call. Link: https://lore.kernel.org/r/1652354134-171343-4-git-send-email-john.garry@huawei.com Fixes: 36c6b761 ("scsi: hisi_sas: Initialise devices in .slave_alloc callback") Tested-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
John Garry authored
We have seen errors like this when a SATA device is probed: [524.566298] hisi_sas_v3_hw 0000L74:02.0: erroneous completion iptt=4096 ... [524.582827] sas: TMF task open reject failed 500e004aaaaaaaa00 Since commit 21c7e972 ("scsi: hisi_sas: Disable SATA disk phy for severe I_T nexus reset failure"), we issue an ATA softreset to disks after a phy reset to ensure that they are in sound working order. If the softreset is issued before the remote phy has come back up then the softreset will fail (errors as above). Remedy this by waiting for the phy to come back up after the reset. Link: https://lore.kernel.org/r/1652354134-171343-3-git-send-email-john.garry@huawei.comTested-by:
-
John Garry authored
Create function sas_ata_wait_after_reset() from sas_ata_hard_reset() as some LLDDs may want to check for a remote ATA phy is up after reset. Link: https://lore.kernel.org/r/1652354134-171343-2-git-send-email-john.garry@huawei.comTested-by:
-
Sreekanth Reddy authored
Update driver version to 42.100.00.00. Link: https://lore.kernel.org/r/20220511072621.30657-2-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Terminate string after copying 16 bytes of ChipName data from Manufacturing Page0 to prevent %s from printing junk characters. Link: https://lore.kernel.org/r/20220511072621.30657-1-sreekanth.reddy@broadcom.comSigned-off-by:
-
- 17 May, 2022 6 commits
-
-
Minghao Chi authored
Use kobj_to_dev() instead of open-coding it. Link: https://lore.kernel.org/r/20220510105113.1351891-1-chi.minghao@zte.com.cnReported-by:
Zeal Robot <zealci@zte.com.cn> Acked-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
-
Dan Carpenter authored
The bsg_setup_queue() function does not return NULL. It returns error pointers. Fix the check accordingly. Link: https://lore.kernel.org/r/YnUf7RQl+A3tigWh@kili Fixes: 4268fa75 ("scsi: mpi3mr: Add bsg device support") Signed-off-by:
-
Sebastian Andrzej Siewior authored
Using get_cpu() leads to disabling preemption and in this context it is not possible to acquire the following spinlock_t on PREEMPT_RT because it becomes a sleeping lock. Commit 0ea5c275 ("[SCSI] bnx2fc: common free list for cleanup commands") says that it is using get_cpu() as a fix in case the CPU is preempted. While this might be true, the important part is that it is now using the same CPU for locking and unlocking while previously it always relied on smp_processor_id(). The date structure itself is protected with a lock so it does not rely on CPU-local access. Replace get_cpu() with raw_smp_processor_id() to obtain the current CPU number which is used as an index for the per-CPU resource. Link: https://lore.kernel.org/r/20220506105758.283887-5-bigeasy@linutronix.deReviewed-by:
Davidlohr Bueso <dave@stgolabs.net> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Davidlohr Bueso authored
The get_cpu() in fc_exch_em_alloc() was introduced in commit f018b73a ("[SCSI] libfc, libfcoe, fcoe: use smp_processor_id() only when preempt disabled") for no other reason than to simply use smp_processor_id() without getting a warning, because everything is done with the pool->lock held anyway. However, get_cpu(), by disabling preemption, does not play well with PREEMPT_RT, particularly when acquiring a regular (and thus sleepable) spinlock. Therefore remove the get_cpu() and just use the unstable value as we will have CPU locality guarantees next by taking the lock. The window of migration, as noted by Sebastian, is small and even if it happens the result is correct. Link: https://lore.kernel.org/r/20211117025956.79616-2-dave@stgolabs.net Link: https://lore.kernel.org/r/20220506105758.283887-4-bigeasy@linutronix.deAcked-by:
Davidlohr Bueso <dbueso@suse.de> Signed-off-by:
-
Sebastian Andrzej Siewior authored
The per-CPU statistics (struct fc_stats) is updated by getting a stable per-CPU pointer via get_cpu() + per_cpu_ptr() and then performing the increment. This can be optimized by using this_cpu_*() which will do whatever is needed on the architecture to perform the update safe and efficient. The read out of the individual value (fc_get_host_stats()) should be done by using READ_ONCE() instead of a plain-C access. The difference is that READ_ONCE() will always perform a single access while the plain-C access can be split by the compiler into two loads if it appears beneficial. The usage of u64 has the side-effect that it is also 64bit wide on 32bit architectures and the read is always split into two loads. The can lead to strange values if the read happens during an update which alters both 32bit parts of the 64bit value. This can be circumvented by either using a 32bit variables on 32bit architecures or extending the statistics with a sequence counter. Use this_cpu_*() API to update the statistics and READ_ONCE() to read it. Link: https://lore.kernel.org/r/20220506105758.283887-3-bigeasy@linutronix.deReviewed-by:
-
Davidlohr Bueso authored
fcoe_get_paged_crc_eof() relies on the caller having preemption disabled to ensure the per-CPU fcoe_percpu context remains valid throughout the call. This is done by either holding spinlocks (such as bnx2fc_global_lock or qedf_global_lock) or the get_cpu() from fcoe_alloc_paged_crc_eof(). This last one breaks PREEMPT_RT semantics as there can be memory allocation and end up sleeping in atomic contexts. Introduce a local_lock_t to struct fcoe_percpu that will keep the non-RT case the same, mapping to preempt_disable/enable, while RT will use a per-CPU spinlock allowing the region to be preemptible but still maintain CPU locality. The other users of fcoe_percpu are already safe in this regard and do not require local_lock()ing. Link: https://lore.kernel.org/r/20211117025956.79616-3-dave@stgolabs.net Link: https://lore.kernel.org/r/20220506105758.283887-2-bigeasy@linutronix.deAcked-by:
-
- 11 May, 2022 12 commits
-
-
Max Gurtovoy authored
The structure iscsi_session naming is used by the iSCSI initiator driver. Rename the target session to iscsit_session to have more readable code. Link: https://lore.kernel.org/r/20220428092939.36768-3-mgurtovoy@nvidia.comReviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Max Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by:
-
Max Gurtovoy authored
The structure iscsi_conn naming is used by the iSCSI initiator driver. Rename the target conn to iscsit_conn to have more readable code. Link: https://lore.kernel.org/r/20220428092939.36768-2-mgurtovoy@nvidia.comReviewed-by:
-
Max Gurtovoy authored
The structure iscsi_cmd naming is used by the iSCSI initiator driver. Rename the target cmd to iscsit_cmd to have more readable code. Link: https://lore.kernel.org/r/20220428092939.36768-1-mgurtovoy@nvidia.comReviewed-by:
-
Sreekanth Reddy authored
Complete all new I/O requests issued to an unrecoverable controller with DID_ERROR status instead of returning the I/O requests with SCSI_MLQUEUE_HOST_BUSY. This will prevent the infinite retries of the new I/Os when a controller is in an unrecoverable state. Link: https://lore.kernel.org/r/20220505184808.24049-1-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
If any drive is missing during reset, the driver checks whether the device is exposed to the OS. If it is, then it removes the device from the OS and its own internal list. For hidden devices, even if they are found as missing during reset, the driver is not removing them from its internal list. Modify driver to remove hidden devices from the driver's target device list if they are missing during soft reset. Link: https://lore.kernel.org/r/20220505184808.24049-2-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Set each SCSI device's default I/O timeout and default error handling I/O timeout to 60s. Link: https://lore.kernel.org/r/20220505184808.24049-3-sreekanth.reddy@broadcom.comSigned-off-by:
-
James Smart authored
Update lpfc version to 14.2.0.3 Link: https://lore.kernel.org/r/20220506035519.50908-13-jsmart2021@gmail.comCo-developed-by:
Justin Tee <justin.tee@broadcom.com> Signed-off-by:
-
James Smart authored
NVMe I/O problems may be seen on IOMMU enabled platforms. Adapter I/Os failing with transfer length mismatches. The sg list processing routine for NVMe I/O is accessing the sg entry directly for the length and address fields. On some IOMMU platforms, contigous mappings are compressed to the first sg entry with the sum of the lengths set to the sg entry dma_length field. The length fields are left for later use by the unmap call. As such, the driver didn't see the actual dma_length value, just the first entries length value. Drivers are to use the sg_dma_length() and sg_dma_address() macros to reference the sg entry. The macros select the proper length field (dma_length or length) to reference. Fix the offending code to use the sg_dma_xxx macros. Link: https://lore.kernel.org/r/20220506035519.50908-12-jsmart2021@gmail.comTested-by:
Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by:
Nigel Kirkland <nkirkland2304@gmail.com> Signed-off-by:
-
James Smart authored
When configuring CMF management based on signals instead of FPINs, FPIN alarm and warning statistics are not tracked. Change the behavior so that FPIN alarms and warnings are always tracked regardless of the configured mode. Similar changes are made in the CMF signal stat accounting logic. Upon receipt of a signal, only track signaled alarms and warnings. FPIN stats should not be incremented upon receipt of a signal. Link: https://lore.kernel.org/r/20220506035519.50908-11-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
After a link up, it's possible for the switch to change FDMI support (e.g. FDMI1 vs FDMI2 vs SmartSAN). If the switch reverts to FDMI1, then the revert is currently not detected. Additionally, when NPIV is configured, it's possible the physical port's RHBA is unprocessed by the switch before reciept of an NPIV port issued RPRT. This causes some switches vendors to reject the NPIV's RPRT. Fix by reinitializing base FDMI mode on link up, and defer FDMI vport RPRT submission until after confirming physical port's RHBA is completed. Link: https://lore.kernel.org/r/20220506035519.50908-10-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
Currently, VMID registration is configured via module parameters. This could lead to VMID compatibility issues if two ports are connected to different brands of switches, as the two brands implement VMID differently. Make logical changes so that VMID registration is based on common service parameters from FLOGI_ACC with fabric rather than module parameters. Link: https://lore.kernel.org/r/20220506035519.50908-9-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
During large NPIV port testing, it was sometimes seen that not all vports would log back in to the target device. There are instances when the fabric is slow to respond to a spam of GID_PT requests and as a result the SLI PORT may abort the GID_PT request because the fabric takes so long. lpfc_cmpl_ct_cmd_gid_pt() would enter the lpfc_err_lost_link() logic and attempt to lpfc_els_flush_rscn(), which is fine, but forgets to decrement the gidft_inp counter. This results in a vport->gidft_inp never reaching 0 and never restarting discovery again. Decrement vport->gidft_inp if lpfc_err_lost_link() is true for both lpfc_cmpl_ct_cmd_gid_pt() and lpfc_cmpl_ct_cmd_gid_ft(). Increase logging info during RSCN timeout and lpfc_err_lost_link() events. Link: https://lore.kernel.org/r/20220506035519.50908-8-jsmart2021@gmail.comCo-developed-by:
-
