- 17 Mar, 2023 4 commits
-
-
Bart Van Assche authored
It is important for the SCSI core to know the residual byte count. Hence, extract the residual byte count from the UFS response and pass it to the SCSI core. A few examples of the output of a debugging patch that has been applied on top of this patch: [ 1.937750] cmd 0x12: len = 255; resid = 241 [ ... ] [ 1.993400] cmd 0xa0: len = 4096; resid = 4048 [ ... ] Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20230314205844.313519-1-bvanassche@acm.orgReviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Bart Van Assche authored
Neither UFS host controllers nor UFS devices require a ten second delay after a host reset or after a bus reset. Hence this patch. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Andy Shevchenko authored
Use %ptTs instead of open-coded variant to print contents of time64_t type in human readable form. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230314145813.66112-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Tom Rix authored
smatch reports several warnings: drivers/scsi/be2iscsi/be_main.c:148:1: warning: symbol 'dev_attr_beiscsi_log_enable' was not declared. Should it be static? drivers/scsi/be2iscsi/be_main.c:158:1: warning: symbol 'dev_attr_beiscsi_drvr_ver' was not declared. Should it be static? drivers/scsi/be2iscsi/be_main.c:159:1: warning: symbol 'dev_attr_beiscsi_adapter_family' was not declared. Should it be static? drivers/scsi/be2iscsi/be_main.c:160:1: warning: symbol 'dev_attr_beiscsi_fw_ver' was not declared. Should it be static? drivers/scsi/be2iscsi/be_main.c:161:1: warning: symbol 'dev_attr_beiscsi_phys_port' was not declared. Should it be static? drivers/scsi/be2iscsi/be_main.c:162:1: warning: symbol 'dev_attr_beiscsi_active_session_count' was not declared. Should it be static? drivers/scsi/be2iscsi/be_main.c:164:1: warning: symbol 'dev_attr_beiscsi_free_session_count' was not declared. Should it be static ? These variables are only used in be_main.c, so should be static. Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20230314005157.536918-1-trix@redhat.comSigned-off-by:
-
- 10 Mar, 2023 35 commits
-
-
Martin K. Petersen authored
Bjorn Helgaas <helgaas@kernel.org> says: Since f26e58bf ("PCI/AER: Enable error reporting when AER is native"), which appeared in v6.0, the PCI core has enabled PCIe error reporting for all devices during enumeration. Remove driver code to do this and remove unnecessary includes of <linux/aer.h> from several other drivers. Signed-off-by:
-
Bjorn Helgaas authored
pci_enable_pcie_error_reporting() enables the device to send ERR_* Messages. Since commit f26e58bf ("PCI/AER: Enable error reporting when AER is native"), the PCI core does this for all devices during enumeration, so the driver doesn't need to do it itself. Remove the redundant pci_enable_pcie_error_reporting() call from the driver. Also remove the corresponding pci_disable_pcie_error_reporting() from the driver .remove() path. Note that this only controls ERR_* Messages from the device. An ERR_* Message may cause the Root Port to generate an interrupt, depending on the AER Root Error Command register managed by the AER service driver. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20230307182842.870378-11-helgaas@kernel.org Cc: Nilesh Javali <njavali@marvell.com> Cc: Manish Rangankar <mrangankar@marvell.com> Cc: GR-QLogic-Storage-Upstream@marvell.com Signed-off-by:
-
Bjorn Helgaas authored
pci_enable_pcie_error_reporting() enables the device to send ERR_* Messages. Since commit f26e58bf ("PCI/AER: Enable error reporting when AER is native"), the PCI core does this for all devices during enumeration, so the driver doesn't need to do it itself. Remove the redundant pci_enable_pcie_error_reporting() call from the driver. Also remove the corresponding pci_disable_pcie_error_reporting() from the driver .remove() path. Note that this only controls ERR_* Messages from the device. An ERR_* Message may cause the Root Port to generate an interrupt, depending on the AER Root Error Command register managed by the AER service driver. Signed-off-by:
-
Bjorn Helgaas authored
pci_enable_pcie_error_reporting() enables the device to send ERR_* Messages. Since commit f26e58bf ("PCI/AER: Enable error reporting when AER is native"), the PCI core does this for all devices during enumeration, so the driver doesn't need to do it itself. Remove the redundant pci_enable_pcie_error_reporting() call from the driver. Also remove the corresponding pci_disable_pcie_error_reporting() from the driver .remove() path. Note that this only controls ERR_* Messages from the device. An ERR_* Message may cause the Root Port to generate an interrupt, depending on the AER Root Error Command register managed by the AER service driver. Signed-off-by:
-
Bjorn Helgaas authored
pci_enable_pcie_error_reporting() enables the device to send ERR_* Messages. Since commit f26e58bf ("PCI/AER: Enable error reporting when AER is native"), the PCI core does this for all devices during enumeration, so the driver doesn't need to do it itself. Remove the redundant pci_enable_pcie_error_reporting() call from the driver. Also remove the corresponding pci_disable_pcie_error_reporting() from the driver .remove() path. Note that this only controls ERR_* Messages from the device. An ERR_* Message may cause the Root Port to generate an interrupt, depending on the AER Root Error Command register managed by the AER service driver. Signed-off-by:
-
Bjorn Helgaas authored
Commit 105a3dbc ("hpsa: clean up driver init") added a comment about pci_disable_pcie_error_reporting(), but hpsa has never called either pci_enable_pcie_error_reporting() or pci_disable_pcie_error_reporting(). Since commit f26e58bf ("PCI/AER: Enable error reporting when AER is native"), the PCI core is responsible for managing PCIe device error reporting. Remove the comment about pci_disable_pcie_error_reporting(). Signed-off-by:
-
Bjorn Helgaas authored
<linux/aer.h> is unused, so remove it. Signed-off-by:
-
Bjorn Helgaas authored
pci_enable_pcie_error_reporting() enables the device to send ERR_* Messages. Since commit f26e58bf ("PCI/AER: Enable error reporting when AER is native"), the PCI core does this for all devices during enumeration, so the driver doesn't need to do it itself. Remove the redundant pci_enable_pcie_error_reporting() call from the driver. Also remove the corresponding pci_disable_pcie_error_reporting() from the driver .remove() path. Note that this only controls ERR_* Messages from the device. An ERR_* Message may cause the Root Port to generate an interrupt, depending on the AER Root Error Command register managed by the AER service driver. Signed-off-by:
-
Bjorn Helgaas authored
pci_enable_pcie_error_reporting() enables the device to send ERR_* Messages. Since commit f26e58bf ("PCI/AER: Enable error reporting when AER is native"), the PCI core does this for all devices during enumeration, so the driver doesn't need to do it itself. Remove the redundant pci_enable_pcie_error_reporting() call from the driver. Also remove the corresponding pci_disable_pcie_error_reporting() from the driver .remove() path. Note that this only controls ERR_* Messages from the device. An ERR_* Message may cause the Root Port to generate an interrupt, depending on the AER Root Error Command register managed by the AER service driver. Signed-off-by:
-
Bjorn Helgaas authored
<linux/aer.h> is unused, so remove it. Signed-off-by:
-
Bjorn Helgaas authored
pci_enable_pcie_error_reporting() enables the device to send ERR_* Messages. Since commit f26e58bf ("PCI/AER: Enable error reporting when AER is native"), the PCI core does this for all devices during enumeration, so the driver doesn't need to do it itself. Remove the redundant pci_enable_pcie_error_reporting() call from the driver. Note that this only controls ERR_* Messages from the device. An ERR_* Message may cause the Root Port to generate an interrupt, depending on the AER Root Error Command register managed by the AER service driver. Also remove pci_disable_pcie_error_reporting() from the .error_detected() path, which was added by commit 5c63f7f7 ("aacraid: Added EEH support") but looks unnecessary. Error reporting will be disabled by the device reset and will be re-enabled by the pci_restore_state() in aac_pci_slot_reset(). Signed-off-by:
-
Martin K. Petersen authored
chenxiang <chenxiang66@hisilicon.com> says: To support IO_URING IOPOLL support for hisi_sas, we need to: - Add and fill mq_poll interface to poll queue; - Ensure internal I/Os (including internal abort I/Os) are delivered and completed through non-iopoll queue (queue 0); Sending internal abort commands to non-poll queue actually requires to sending the abort command to every queue. This carries a a risk. Make iopoll support module parameter "experimental". I have tested performance on v3 hw with different modes as follows. 4K READs and 4K WRITEs both see an improvement when enabling poll mode: 4K READ 4K RANDREAD 4K WRITE 4K RANDWRITE interrupt + libaio 1770k 1316k 1197k 831k interrupt + io_uring 1848k 1390k 1238k 857k iopoll + io_uring 2117k 1364k 1874k 849k Signed-off-by: -
Xiang Chen authored
Add device attribute experimental_iopoll_q_cnt to indicate how many iopoll queues are used for v3 hw. Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Link: https://lore.kernel.org/r/1678169355-76215-5-git-send-email-chenxiang66@hisilicon.comSigned-off-by:
-
Xiang Chen authored
Currently we sync irq to avoid freeing task before using task in I/O completion. After adding io_uring support, we need to do something similar for poll queues. As the process of CQ entries on poll queue are protected by spinlock cq->lock, we can use spin_lock() + spin_unlock() on cq->lock to make sure that CQ entries are processed to completion and then the complete queue is synced. Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Xiang Chen authored
Add a module parameter to set how many queues are used for iopoll. Also fill the interface mq_poll. For internal I/Os from libsas and libata we use non-iopoll queue (queue 0) to deliver and complete them. But for internal abort I/Os, just don't send them for poll queues. There is still a risk associated as this sends internal abort commands to non-iopoll queues which actually requires sending an internal abort command to every queue. As a result, make the module parameter as "experimental" for now. Signed-off-by:
-
Xiang Chen authored
Put the work of processing cq slots in a separate function, complete_v3_hw(), which can then be used by cq_thread_v3_hw() and other functions when adding poll support. Co-developed-by:
-
Martin K. Petersen authored
Dmitry Bogdanov <d.bogdanov@yadro.com> says: SAM-5 4.6.5.2 (Relative Port Identifier attribute) defines the attribute as unique across SCSI target ports: The Relative Port Identifier attribute identifies a SCSI target port or a SCSI initiator port relative to other SCSI ports in a SCSI target device and any SCSI initiator devices contained within that SCSI target device. A SCSI target device may assign relative port identifiers to its SCSI target ports and any SCSI initiator ports. If relative port identifiers are assigned, the SCSI target device shall assign each of its SCSI target ports and any SCSI initiator ports a unique relative port identifier from 1 to 65 535. SCSI target ports and SCSI initiator ports share the same number space. In the current TCM implementation, auto-incremented lun_rtpi weakly follows the model outlined by SAM-5 and SPC-4. In case of multiple SCSI target ports (se_portal_groups), which is common to scenario with multiple HBAs or multiple iSCSI/FC targets, it's possible to have two backstores (se_devices) with different values of lun_rtpi on the same SCSI target port. Similar issue happens during re-export. If a LUN of a backstore is removed from a target port and added again to the same target port, RTPI is incremented again and will be different from the first time. The two issues happen because each se_device increments RTPI for its own LUNs independently. The behaviour means that a SCSI application client can't reliably make any sense of RTPI values reported by a LUN as it's not really related to SCSI target ports. A conforming target implementation must ensure that RTPI field is unique per port. The patchset resolves the issue. Make RTPI be part of se_tpg instead of se_lun. Make it configurable. Signed-off-by: -
Dmitry Bogdanov authored
RELATIVE TARGET PORT IDENTIFIER can be read and configured via configfs: $ echo 0x10 > $TARGET/tpgt_N/rtpi RTPI can be changed only on disabled target ports. Co-developed-by:
Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by:
Dmitry Bogdanov <d.bogdanov@yadro.com> Link: https://lore.kernel.org/r/20230301084512.21956-5-d.bogdanov@yadro.comReviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
-
Roman Bolshakov authored
The code is not needed since target port-based RTPI allocation replaced it. Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Roman Bolshakov authored
Replace all references to RTPI from LUN field to se_portal_group field. It introduces consistent reporting of RTPI for all LUNs and all target ports. Reviewed-by:
-
Dmitry Bogdanov authored
SAM-5 4.6.5.2 (Relative Port Identifier attribute) defines the attribute as unique across SCSI target ports. The change introduces RTPI attribute to se_portal group. The value is unique across all enabled SCSI target ports. It also limits number of SCSI target ports to 65535. Signed-off-by:
-
Martin K. Petersen authored
Justin Tee <justin.tee@broadcom.com> says: Update lpfc to revision 14.2.0.11 This patch set contains bug fixes for buffer overflow, resource management, discovery, and HBA error status handling. The patches were cut against Martin's 6.3/scsi-queue tree. Justin Tee (10): lpfc: Protect against potential lpfc_debugfs_lockstat_write buffer overflow lpfc: Reorder freeing of various dma buffers and their list removal lpfc: Fix lockdep warning for rx_monitor lock when unloading driver lpfc: Record LOGO state with discovery engine even if aborted lpfc: Defer issuing new PLOGI if received RSCN before completing REG_LOGIN lpfc: Correct used_rpi count when devloss tmo fires with no recovery lpfc: Skip waiting for register ready bits when in unrecoverable state lpfc: Revise lpfc_error_lost_link reason code evaluation logic lpfc: Update lpfc version to 14.2.0.11 lpfc: Copyright updates for 14.2.0.11 patches Signed-off-by: -
Justin Tee authored
Update copyrights to 2023 for files modified in the 14.2.0.11 patch set. Signed-off-by:
Justin Tee <justin.tee@broadcom.com> Link: https://lore.kernel.org/r/20230301231626.9621-11-justintee8345@gmail.comSigned-off-by:
-
Justin Tee authored
Update lpfc version to 14.2.0.11. Signed-off-by:
-
Justin Tee authored
Extended status reason code errors should mask off the IOERR_PARAM_MASK before checking strict equalities for IOERR values. Update the lpfc_error_lost_link() routine as such. Signed-off-by:
-
Justin Tee authored
During tolerance tests that force an HBA to become unresponsive, rmmod hangs resulting in the inability to remove the driver. The lpfc_pci_remove_one_s4() routine attempts to submit a clean up mailbox command via the lpfc_sli4_post_sync_mbox() routine, but ends up waiting forever for a mailbox register to set its ready bit. Because the HBA is in an unrecoverable and unresponsive state, the ready bit will never be set. Create a new routine called lpfc_sli4_unrecoverable_port(), which checks a port status register's error notification bits. Use the lpfc_sli4_unrecoverable_port() routine in ready bit check routines to early return error if port is deemed unrecoverable. Also, when the lpfc_handle_eratt_s4() handler detects an unrecoverable state, call the lpfc_sli4_offline_eratt() routine to kick off flushing outstanding I/O. Signed-off-by:
-
Justin Tee authored
A fabric controller can sometimes send an RDP request right before a link down event. Because of this outstanding RDP request, the driver does not remove the last reference count on its ndlp causing a potential leak of RPI resources when devloss tmo fires. In lpfc_cmpl_els_rsp(), modify the NPIV clause to always allow the lpfc_drop_node() routine to execute when not registered with SCSI transport. This relaxes the contraint that an NPIV ndlp must be in a specific state in order to call lpfc_drop node. Logic is revised such that the lpfc_drop_node() routine is always called to ensure the last ndlp decrement occurs. Signed-off-by:
-
Justin Tee authored
When mapped to a target with multiple virtual ports, a link bounce sometimes results in unsuccessful rediscovery of all of the target's virtual ports. This is because a succession of repeat RSCNs for the virtual target ports leaves ndlps in the REG_LOGIN state with the NLP_REG_LOGIN_SEND flag set. With NLP_REG_LOGIN_SEND set, during the next PLOGI, the driver will UNREG_RPI. When UNREG_RPI is processed, the driver can be in the middle of PRLI_ISSUE or MAPPED state resulting in an illegal state transition by the discovery engine and stalling. Fix by calling the discovery state machine with DEVICE_RECOVERY event during RSCN processing. This will set the NLP_IGNR_REG_CMPL bit and prevent the old REG_LOGIN state from advancing. Then for the new PLOGI issue, add the check for the NLP_IGNR_REG_CMPL bit to delay issuing the new PLOGI until the queued REG_LOGIN and UNREG_LOGIN have been processed. Signed-off-by:
-
Justin Tee authored
A target vendor array reboot in P2P topology can sometimes result in unsuccessful rediscovery. Rework the lpfc_cmpl_els_logo() routine such that when the LOGO completes as a failure because of driver abort, the LOGO state is still recorded with the discovery state machine. This is a small rework to set LOGO completion without forcing a device removal state change. Signed-off-by:
-
Justin Tee authored
Lockdep enabled kernels report a theoretical deadlock state where the cmf_timer interrupt occurs while the rx_monitor ring is being destroyed. During rmmod, the cmf_timer is cancelled prior to the lpfc_rx_monitor_destroy_ring call. This actually eliminates the need to take the rx_monitor ring lock in lpfc_rx_monitor_destroy_ring. Thus, just remove lock/unlock of rx_monitor in lpfc_rx_monitor_destroy_ring. Signed-off-by:
-
Justin Tee authored
Code sections where DMA resources are freed before list removal are reworked to ensure item removal before being freed. Signed-off-by:
-
Justin Tee authored
A static code analysis tool flagged the possibility of buffer overflow when using copy_from_user() for a debugfs entry. Currently, it is possible that copy_from_user() copies more bytes than what would fit in the mybuf char array. Add a min() restriction check between sizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protect against buffer overflow. Link: https://lore.kernel.org/r/20230301231626.9621-2-justintee8345@gmail.comSigned-off-by:
-
Tetsuo Handa authored
Like commit c4f135d6 ("workqueue: Wrap flush_workqueue() using a macro") says, flush_scheduled_work() is dangerous and will be forbidden. Commit 4d4109d0 ("[SCSI] mpt fusion: Power Management fixes for MPT SAS PCI-E controllers") added flush_scheduled_work() call into mptscsih_suspend(). As of commit 4d4109d0, there were several schedule{,_delayed}_work() calls where flush_scheduled_work() from mptscsih_suspend() meant to wait for completion. However, which work items this flush_scheduled_work() call was for was not explained. Then, schedule_work("struct mptsas_hotplug_event"->work) and schedule_work(MPT_ADAPTER->sas_persist_task) have been removed by commit 3eb0822c ("[SCSI] mpt fusion: Firmware event implementation using seperate WorkQueue"), and schedule_work("struct mptsas_send_discovery_event"->work) has been removed by commit f9c34022 ("[SCSI] mpt fusion: SAS topology scan changes, expander events"). There still remains schedule_work("struct work_queue_wrapper"->work) call in mptspi.c and schedule_delayed_work("struct mpt_lan_priv"->work) call in mptlan.c , but I guess that these are not work items which commit 4d4109d0 meant to wait for completion because these are not per MPT_ADAPTER work items. If my guess is correct, we no longer need to call flush_scheduled_work() from mptscsih_suspend(). Link: https://lore.kernel.org/r/0b9ebcfb-b647-1381-0653-b54528a64a86@I-love.SAKURA.ne.jpSigned-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
-
Tetsuo Handa authored
MPT_ADAPTER->sas_persist_task is no longer used since commit 3eb0822c ("[SCSI] mpt fusion: Firmware event implementation using seperate WorkQueue"). Link: https://lore.kernel.org/r/b2ca2164-5347-8ec1-d8b6-3225df864173@I-love.SAKURA.ne.jpSigned-off-by:
-
Jiapeng Chong authored
The variable 'internal_page_offset' is not used. Delete it. drivers/scsi/be2iscsi/be_cmds.c:1176:6: warning: variable 'internal_page_offset' set but not used. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4011Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20230209035224.90327-1-jiapeng.chong@linux.alibaba.comSigned-off-by:
-
- 05 Mar, 2023 1 commit
-
-
Linus Torvalds authored
-
