kernel.git/drivers/scsi/libsas, branch linux-6.10.y

Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2024-07-02T05:57:03Z

Pull SCSI fixes from James Bottomley: "A couple of error leg problems, one affecting scsi_debug and the other affecting pure SAS (i.e. not SATA) SCSI expanders" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: libsas: Fix exp-attached device scan after probe failure scanned in again after probe failed scsi: scsi_debug: Fix create target debugfs failure

ata,scsi: libata-core: Do not leak memory for ata_port struct members

2024-06-30T20:23:21Z

libsas is currently not freeing all the struct ata_port struct members, e.g. ncq_sense_buf for a driver supporting Command Duration Limits (CDL). Add a function, ata_port_free(), that is used to free a ata_port, including its struct members. It makes sense to keep the code related to freeing a ata_port in its own function, which will also free all the struct members of struct ata_port. Fixes: 18bd7718b5c4 ("scsi: ata: libata: Handle completion of CDL commands using policy 0xD") Reviewed-by: John Garry Link: https://lore.kernel.org/r/20240629124210.181537-8-cassel@kernel.org Signed-off-by: Niklas Cassel

scsi: libsas: Fix exp-attached device scan after probe failure scanned in again after probe failed

2024-06-27T02:31:53Z

The expander phy will be treated as broadcast flutter in the next revalidation after the exp-attached end device probe failed, as follows: [78779.654026] sas: broadcast received: 0 [78779.654037] sas: REVALIDATING DOMAIN on port 0, pid:10 [78779.654680] sas: ex 500e004aaaaaaa1f phy05 change count has changed [78779.662977] sas: ex 500e004aaaaaaa1f phy05 originated BROADCAST(CHANGE) [78779.662986] sas: ex 500e004aaaaaaa1f phy05 new device attached [78779.663079] sas: ex 500e004aaaaaaa1f phy05:U:8 attached: 500e004aaaaaaa05 (stp) [78779.693542] hisi_sas_v3_hw 0000:b4:02.0: dev[16:5] found [78779.701155] sas: done REVALIDATING DOMAIN on port 0, pid:10, res 0x0 [78779.707864] sas: Enter sas_scsi_recover_host busy: 0 failed: 0 ... [78835.161307] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1 [78835.171344] sas: sas_probe_sata: for exp-attached device 500e004aaaaaaa05 returned -19 [78835.180879] hisi_sas_v3_hw 0000:b4:02.0: dev[16:5] is gone [78835.187487] sas: broadcast received: 0 [78835.187504] sas: REVALIDATING DOMAIN on port 0, pid:10 [78835.188263] sas: ex 500e004aaaaaaa1f phy05 change count has changed [78835.195870] sas: ex 500e004aaaaaaa1f phy05 originated BROADCAST(CHANGE) [78835.195875] sas: ex 500e004aaaaaaa1f rediscovering phy05 [78835.196022] sas: ex 500e004aaaaaaa1f phy05:U:A attached: 500e004aaaaaaa05 (stp) [78835.196026] sas: ex 500e004aaaaaaa1f phy05 broadcast flutter [78835.197615] sas: done REVALIDATING DOMAIN on port 0, pid:10, res 0x0 The cause of the problem is that the related ex_phy's attached_sas_addr was not cleared after the end device probe failed, so reset it. Signed-off-by: Xingui Yang Link: https://lore.kernel.org/r/20240619091742.25465-1-yangxingui@huawei.com Reviewed-by: John Garry Signed-off-by: Martin K. Petersen

Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2024-05-15T01:25:53Z

Pull SCSI updates from James Bottomley: "Updates to the usual drivers (ufs, lpfc, qla2xxx, mpi3mr, libsas). The major update (which causes a conflict with block, see below) is Christoph removing the queue limits and their associated block helpers. The remaining patches are assorted minor fixes and deprecated function updates plus a bit of constification" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (141 commits) scsi: mpi3mr: Sanitise num_phys scsi: lpfc: Copyright updates for 14.4.0.2 patches scsi: lpfc: Update lpfc version to 14.4.0.2 scsi: lpfc: Add support for 32 byte CDBs scsi: lpfc: Change lpfc_hba hba_flag member into a bitmask scsi: lpfc: Introduce rrq_list_lock to protect active_rrq_list scsi: lpfc: Clear deferred RSCN processing flag when driver is unloading scsi: lpfc: Update logging of protection type for T10 DIF I/O scsi: lpfc: Change default logging level for unsolicited CT MIB commands scsi: target: Remove unused list 'device_list' scsi: iscsi: Remove unused list 'connlist_err' scsi: ufs: exynos: Add support for Tensor gs101 SoC scsi: ufs: exynos: Add some pa_dbg_ register offsets into drvdata scsi: ufs: exynos: Allow max frequencies up to 267Mhz scsi: ufs: exynos: Add EXYNOS_UFS_OPT_TIMER_TICK_SELECT option scsi: ufs: exynos: Add EXYNOS_UFS_OPT_UFSPR_SECURE option scsi: ufs: dt-bindings: exynos: Add gs101 compatible scsi: qla2xxx: Fix debugfs output for fw_resource_count scsi: qedf: Ensure the copied buf is NUL terminated scsi: bfa: Ensure the copied buf is NUL terminated ...

Merge patch series "scsi: libsas: Fix the failure of adding phy with zero-address to new port"

2024-04-20T14:40:04Z

Xingui Yang says: This series is to solve the problem of a BUG() when adding phy with zero address to a new port. Link: https://lore.kernel.org/r/20240312141103.31358-1-yangxingui@huawei.com Signed-off-by: Martin K. Petersen

scsi: libsas: Fix the failure of adding phy with zero-address to port

2024-04-20T14:38:44Z

As of commit 7d1d86518118 ("[SCSI] libsas: fix false positive 'device attached' conditions"), reset the phy->entacted_sas_addr address to a zero-address when the link rate is less than 1.5G. Currently we find that when a new device is attached, and the link rate is less than 1.5G, but the device type is not NO_DEVICE, for example: the link rate is SAS_PHY_RESET_IN_PROGRESS and the device type is stp. After setting the phy->entacted_sas_addr address to the zero address, the port will continue to be created for the phy with the zero-address, and other phys with the zero-address will be tried to be added to the new port: [562240.051197] sas: ex 500e004aaaaaaa1f phy19:U:0 attached: 0000000000000000 (no device) // phy19 is deleted but still on the parent port's phy_list [562240.062536] sas: ex 500e004aaaaaaa1f phy0 new device attached [562240.062616] sas: ex 500e004aaaaaaa1f phy00:U:5 attached: 0000000000000000 (stp) [562240.062680] port-7:7:0: trying to add phy phy-7:7:19 fails: it's already part of another port Therefore, it should be the same as sas_get_phy_attached_dev(). Only when device_type is SAS_PHY_UNUSED, sas_address is set to the 0 address. Fixes: 7d1d86518118 ("[SCSI] libsas: fix false positive 'device attached' conditions") Signed-off-by: Xingui Yang Link: https://lore.kernel.org/r/20240312141103.31358-5-yangxingui@huawei.com Signed-off-by: Martin K. Petersen

scsi: libsas: Set port when ex_phy is added or deleted

2024-04-20T14:38:44Z

We found that when ex_phy was attached and added to the parent wide port, ex_phy->port was not set, resulting in sas_unregister_devs_sas_addr() not calling sas_port_delete_phy() when deleting the phy, and the deleted phy was still on the parent wide port's phy_list. When we use sas_port_add_ex_phy() to set ex_phy->port to solve the above problem, we find that after all the phys of the parent_port are removed and the number of phy becomes 0, the parent_port will not be set to NULL. This causes the freed parent port to be used when attaching a new ex_phy in sas_ex_add_parent_port(). Use sas_port_add_ex_phy() instead of sas_port_add_phy() to set ex_phy->port when ex_phy is added to the parent port, and set ex_dev->parent_port to NULL when the number of phy on the port becomes 0. Signed-off-by: Xingui Yang Link: https://lore.kernel.org/r/20240312141103.31358-4-yangxingui@huawei.com Signed-off-by: Martin K. Petersen

scsi: libsas: Move sas_add_parent_port() to sas_expander.c

2024-04-20T14:38:43Z

Move sas_add_parent_port() to sas_expander.c and rename it to sas_ex_add_parent_port() as it is only used in this file. Signed-off-by: Xingui Yang Link: https://lore.kernel.org/r/20240312141103.31358-3-yangxingui@huawei.com Reviewed-by: John Garry Signed-off-by: Martin K. Petersen

scsi: libsas: Add helper for port add ex_phy

2024-04-20T14:38:43Z

This moves the process of adding ex_phy to a port into a new helper. Signed-off-by: Xingui Yang Link: https://lore.kernel.org/r/20240312141103.31358-2-yangxingui@huawei.com Reviewed-by: John Garry Signed-off-by: Martin K. Petersen

scsi: libata: Switch to using ->device_configure

2024-04-12T01:37:50Z

Switch to the ->device_configure method instead of ->slave_configure and update the block limits on the passed in queue_limits instead of using the per-limit accessors. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20240409143748.980206-21-hch@lst.de Reviewed-by: John Garry Reviewed-by: Hannes Reinecke Acked-by: Damien Le Moal Signed-off-by: Martin K. Petersen