- 13 Apr, 2021 22 commits
-
-
Sergey Shtylyov authored
Commit df2d8213 ("hisi_sas: use platform_get_irq()") failed to take into account that irq_of_parse_and_map() and platform_get_irq() have a different way of indicating an error: the former returns 0 and the latter returns a negative error code. Fix up the IRQ checks! Link: https://lore.kernel.org/r/810f26d3-908b-1d6b-dc5c-40019726baca@omprussia.ru Fixes: df2d8213 ("hisi_sas: use platform_get_irq()") Acked-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Sergey Shtylyov authored
The driver overrides the error codes returned by platform_get_irq() to -ENODEV, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Propagate the error code upstream as it should have been done from the start... Link: https://lore.kernel.org/r/420364ca-614a-45e3-4e35-0e0653c7bc53@omprussia.ru Fixes: 2953f850 ("[SCSI] ufs: use devres functions for ufshcd") Signed-off-by:
-
dingsenjie authored
Use DEFINE_SHOW_ATTRIBUTE() macro to simplify the code. Link: https://lore.kernel.org/r/20210331065326.18804-1-dingsenjie@163.comSigned-off-by:
dingsenjie <dingsenjie@yulong.com> Signed-off-by:
-
Ye Bin authored
There is a error message within devm_ioremap_resource() already, so remove the dev_err() call to avoid redundant error message. Link: https://lore.kernel.org/r/20210409075522.2111083-1-yebin10@huawei.comReported-by:
Hulk Robot <hulkci@huawei.com> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Ye Bin <yebin10@huawei.com> Signed-off-by:
-
Luo Jiaxing authored
Add (pseudo) SAS address for ATA software reset failure log to assist in debugging. Link: https://lore.kernel.org/r/1617709711-195853-7-git-send-email-john.garry@huawei.comSigned-off-by:
Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by:
-
Luo Jiaxing authored
If a channel interrupt occurs without any status bit set, the handler will return directly. However, if such redundant interrupts are received, it's better to check what happen, so add logs for this. Link: https://lore.kernel.org/r/1617709711-195853-6-git-send-email-john.garry@huawei.comSigned-off-by:
Yihang Li <liyihang6@hisilicon.com> Signed-off-by:
-
Jianqin Xie authored
The debugfs snapshot should be executed before the reset occurs to ensure that the register contents are saved properly. As such, it is incorrect to queue the debugfs dump when running a reset as the reset will occur prior to the snapshot work item is handler. Therefore, directly snapshot registers in the reset work handler. Link: https://lore.kernel.org/r/1617709711-195853-5-git-send-email-john.garry@huawei.comSigned-off-by:
Jianqin Xie <xiejianqin@hisilicon.com> Signed-off-by:
-
Xiang Chen authored
Function sas_unregister_ha() needs to be called to roll back if hisi_hba->hw->hw_init() fails in function hisi_sas_probe() or hisi_sas_v3_probe(). Make that change. Link: https://lore.kernel.org/r/1617709711-195853-4-git-send-email-john.garry@huawei.comSigned-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
Luo Jiaxing authored
To help debugging efforts, print the device SAS address for v3 hw erroneous completion log. Here is an example print: hisi_sas_v3_hw 0000:b4:02.0: erroneous completion iptt=2193 task=000000002b0c13f8 dev id=17 addr=570fd45f9d17b001 Link: https://lore.kernel.org/r/1617709711-195853-3-git-send-email-john.garry@huawei.comSigned-off-by:
-
Luo Jiaxing authored
The debugfs code has been relocated to v3 hw driver, so delete unused struct hisi_sas_hw function pointers snapshot_{prepare, restore}. Link: https://lore.kernel.org/r/1617709711-195853-2-git-send-email-john.garry@huawei.comSigned-off-by: -
Luo Jiaxing authored
checkpatch reports the following: ERROR: that open brace { should be on the previous line +static struct error_fw flash_error_table[] = +{ Fix a couple of instances of misplaced open bracket. Link: https://lore.kernel.org/r/1617886593-36421-3-git-send-email-luojiaxing@huawei.comAcked-by:Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
-
Luo Jiaxing authored
checkpatch reports the following: ERROR: space prohibited before that ',' (ctx:WxW) +int pm8001_mpi_general_event(struct pm8001_hba_info *pm8001_ha , void *piomb); Remove unnecessary whitespace. Link: https://lore.kernel.org/r/1617886593-36421-2-git-send-email-luojiaxing@huawei.comAcked-by: -
Colin Ian King authored
The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of pm8001_ha->max_q_num which is a u32 type. There is a potential infinite loop if pm8001_ha->max_q_num is larger than the u8 loop counter. Fix this by making the loop counter the same type as pm8001_ha->max_q_num. [mkp: this is purely theoretical, max_q_num is currently limited to 64] Link: https://lore.kernel.org/r/20210407135840.494747-1-colin.king@canonical.com Fixes: 65df7d19 ("scsi: pm80xx: Fix chip initialization failure") Addresses-Coverity: ("Infinite loop") Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Igor Pylypiv authored
mpi_uninit_check() is not being called in an atomic context. The only caller of mpi_uninit_check() is pm80xx_chip_soft_rst(). Callers of pm80xx_chip_soft_rst(): - pm8001_ioctl_soft_reset() - pm8001_pci_probe() - pm8001_pci_remove() - pm8001_pci_suspend() - pm8001_pci_resume() There was a similar fix for mpi_init_check() in commit d71023af ("scsi: pm80xx: Do not busy wait in MPI init check") Link: https://lore.kernel.org/r/20210406180534.1924345-3-ipylypiv@google.comReviewed-by:
Vishakha Channapattan <vishakhavc@google.com> Acked-by:
Igor Pylypiv <ipylypiv@google.com> Signed-off-by:
-
Igor Pylypiv authored
The mpi_uninit_check() takes longer for inbound doorbell register to be cleared. Increase the timeout substantially so that the driver does not fail to load. Previously, the inbound doorbell wait time was mistakenly increased in the mpi_init_check() instead of mpi_uninit_check(). It is okay to leave the mpi_init_check() wait time as-is as these are timeout values and if there is a failure, waiting longer is not an issue. Link: https://lore.kernel.org/r/20210406180534.1924345-2-ipylypiv@google.com Fixes: e90e2362 ("scsi: pm80xx: Increase timeout for pm80xx mpi_uninit_check") Reviewed-by:
-
Bodo Stroesser authored
Make data_pages_per_blk changeable similar to the way it is done for max_data_area_mb. One can change the value by typing: echo "data_pages_per_blk=N" >control The value is printed when doing: cat info In addition, a new readonly attribute 'data_pages_per_blk' returns the value on read. Link: https://lore.kernel.org/r/20210324195758.2021-7-bostroesser@gmail.comSigned-off-by:
Bodo Stroesser <bostroesser@gmail.com> Signed-off-by:
-
Bodo Stroesser authored
Replace DATA_PAGES_PER_BLK and DATA_BLOCK_SIZE with new struct elements tcmu_dev->data_pages_per_blk and tcmu_dev->data_blk_size. These new variables are still loaded with constant definition DATA_PAGES_PER_BLK_DEF (= 1) and DATA_PAGES_PER_BLK_DEF * PAGE_SIZE. There is no way yet to set the values via configfs. Link: https://lore.kernel.org/r/20210324195758.2021-6-bostroesser@gmail.comSigned-off-by:
-
Bodo Stroesser authored
There is only one caller of tcmu_get_block_page left. Since it is a one-liner, we can remove the function. Link: https://lore.kernel.org/r/20210324195758.2021-5-bostroesser@gmail.comSigned-off-by:
-
Bodo Stroesser authored
Change tcmu to support DATA_BLOCK_SIZE being a multiple of PAGE_SIZE. There are two reasons why one would like to have a bigger DATA_BLOCK_SIZE: 1) If userspace - e.g. due to data compression, encryption or deduplication - needs to have receive or transmit data in a consecutive buffer, we can define DATA_BLOCK_SIZE to the maximum size of a SCSI READ/WRITE to enforce that userspace sees just one consecutive buffer. That way we can avoid the need for doing data copy in userspace. 2) Using a bigger data block size can speed up command processing in tcmu. The number of free data blocks to look up in bitmap is reduced substantially. The lookup for data pages in radix_tree can be done more efficiently if there are multiple pages in a data block. The maximum number of IOVs to set up is lower so cmd entries in the ring become smaller. Link: https://lore.kernel.org/r/20210324195758.2021-4-bostroesser@gmail.comSigned-off-by: -
Bodo Stroesser authored
Rename some variables and definitions as a first preparation for DATA_BLOCK_SIZE != PAGE_SIZE and add the new DATA_PAGES_PER_BLK definition containing the number of pages per data block. Rename tcmu_try_get_block_page() to tcmu_try_get_data_page(). Keep name tcmu_get_block_page() since it will go away in a following commit when there is only one caller left. Subsequent commits will then add full support for DATA_PAGES_PER_BLK != 1, which also means DATA_BLOCK_SIZE = DATA_PAGES_PER_BLK * PAGE_SIZE Link: https://lore.kernel.org/r/20210324195758.2021-3-bostroesser@gmail.comSigned-off-by:
-
Bodo Stroesser authored
Some definitions and members of struct tcmu_dev had misleading names. Examples: - ring_size was used for the size of mailbox + cmd ring + data area - CMDR_SIZE was used for size of mailbox + cmd ring I added the new definition MB_CMDR_SIZE (mailbox + command ring), changed CMDR_SIZE to hold the size of the command ring only and replaced in struct tcmu_dev the member ring_size with mmap_pages, because the member is now used in tcmu_mmap() only, where we need page count, not size. I also added the new struct tcmu_dev member 'cmdr' which is used to replace some occurences of '(void *)mb + CMDR_OFF' with 'udev->cmdr' for better readability. Link: https://lore.kernel.org/r/20210324195758.2021-2-bostroesser@gmail.comSigned-off-by:
-
Martin K. Petersen authored
Resolve a couple of conflicts between the 5.12 fixes branch and the 5.13 staging tree (iSCSI target and UFS). Signed-off-by:
-
- 06 Apr, 2021 18 commits
-
-
Luo Jiaxing authored
checkpatch reported several whitespace errors. Fix them all. Link: https://lore.kernel.org/r/1616675396-6108-3-git-send-email-luojiaxing@huawei.comSigned-off-by:
-
Luo Jiaxing authored
checkpatch reported an error in sas_to_ata_err(). switch and case statements are incorrectly indented. Link: https://lore.kernel.org/r/1616675396-6108-2-git-send-email-luojiaxing@huawei.comSigned-off-by:
-
Tian Tao authored
Remove unnecessary include of linux/version.h. Link: https://lore.kernel.org/r/1617283618-19346-1-git-send-email-tiantao6@hisilicon.comSigned-off-by:
Tian Tao <tiantao6@hisilicon.com> Signed-off-by:
Zhiqi Song <songzhiqi1@huawei.com> Signed-off-by:
-
Wan Jiabing authored
struct bfa_fcs_s is declared twice. First is declared at line 50, remove the duplicate. struct bfa_fcs_fabric_s is defined at line 175, remove unnecessary declaration. Link: https://lore.kernel.org/r/20210401063535.992487-1-wanjiabing@vivo.comSigned-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Fix the following out-of-bounds warnings by enclosing some structure members into new structure objects upiu_req and upiu_rsp: include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [29, 48] from the object at 'treq' is out of the bounds of referenced subobject 'req_header' with type 'struct utp_upiu_header' at offset 16 [-Warray-bounds] include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [61, 80] from the object at 'treq' is out of the bounds of referenced subobject 'rsp_header' with type 'struct utp_upiu_header' at offset 48 [-Warray-bounds] arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' offset [29, 48] from the object at 'treq' is out of the bounds of referenced subobject 'req_header' with type 'struct utp_upiu_header' at offset 16 [-Warray-bounds] arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' offset [61, 80] from the object at 'treq' is out of the bounds of referenced subobject 'rsp_header' with type 'struct utp_upiu_header' at offset 48 [-Warray-bounds] Refactor the code by making it more structured. The problem is that the original code is trying to copy data into a bunch of struct members adjacent to each other in a single call to memcpy(). Now that a new struct _upiu_req_ enclosing all those adjacent members is introduced, memcpy() doesn't overrun the length of &treq.req_header, because the address of the new struct object _upiu_req_ is used as the destination, instead. The same problem is present when memcpy() overruns the length of the source &treq.rsp_header; in this case the address of the new struct object _upiu_rsp_ is used, instead. Also, this helps with the ongoing efforts to enable -Warray-bounds and avoid confusing the compiler. Link: https://github.com/KSPP/linux/issues/109 Link: https://lore.kernel.org/lkml/60640558.lsAxiK6otPwTo9rv%25lkp@intel.com/ Link: https://lore.kernel.org/r/20210331224338.GA347171@embeddedorReported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Yang Yingliang authored
The spinlock and list head of fnic_list are initialized statically. It is unnecessary to initialize them. Link: https://lore.kernel.org/r/20210330125911.1050879-1-yangyingliang@huawei.comReported-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
zhouchuangao authored
BUG_ON() uses unlikely in if() which can be optimized at compile time. Link: https://lore.kernel.org/r/1617108361-6870-1-git-send-email-zhouchuangao@vivo.comSigned-off-by:
zhouchuangao <zhouchuangao@vivo.com> Signed-off-by:
-
Sreekanth Reddy authored
While diag reset is in progress there is short duration where all access to controller's PCI config space from the host needs to be blocked. This is due to a hardware limitation of the IOC controllers. Block all access to controller's config space from userland applications by calling pci_cfg_access_lock() while diag reset is in progress and unlocking it again after the controller comes back to ready state. Link: https://lore.kernel.org/r/20210330105137.20728-1-sreekanth.reddy@broadcom.com Cc: stable@vger.kernel.org #v5.4.108+ Signed-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
Covert ActiveCablePowerRequirement's value to target CPU endian before displaying it. Link: https://lore.kernel.org/r/20210330105106.20569-1-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Whenever the driver is adding a vSES to virtual-phys list it is reinitializing the list head. Hence those vSES devices which were added previously are lost. Stop reinitializing the list every time a new vSES device is added. Link: https://lore.kernel.org/r/20210330105004.20413-1-sreekanth.reddy@broadcom.com Cc: stable@vger.kernel.org #v5.11.10+ Signed-off-by:
-
Konstantin Shelekhin authored
Create the device for the virtual LUN 0 using the DUMMY flag. This change makes it possible to remove some special-casing in the INQUIRY code. Link: https://lore.kernel.org/r/20210322200938.53300-3-k.shelekhin@yadro.comReviewed-by:
Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Konstantin Shelekhin <k.shelekhin@yadro.com> Signed-off-by:
-
Konstantin Shelekhin authored
This commit adds the DUMMY flag to the rd_mcp backend that forces a logical unit to report itself as not connected device of an unknown type. Essentially this allows users to create devices identical to the device for the virtual LUN 0, making it possible to explicitly create a LUN 0 device and configure its WWNs (e.g. vendor or product name). Link: https://lore.kernel.org/r/20210322200938.53300-2-k.shelekhin@yadro.comReviewed-by:
-
Ewan D. Milne authored
Some arrays return ILLEGAL_REQUEST with ASC 00h if they don't support the RTPG extended header so remove the check for INVALID FIELD IN CDB. Link: https://lore.kernel.org/r/20210331201154.20348-1-emilne@redhat.comReviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
John Pittman authored
Due to the frequency that alua_rtpg() is called, the path group info print within can print the same info multiple times in the logs, subsequent prints adding no new information or value. To reproduce: # modprobe scsi_debug vpd_use_hostno=0 # systemctl start multipathd.service To fix, check stored values, only printing at alua attach/activate and if any of the values change. Link: https://lore.kernel.org/r/20210331181656.5046-1-jpittman@redhat.comReviewed-by:David Jeffery <djeffery@redhat.com> Reviewed-by:
Laurence Oberman <loberman@redhat.com> Signed-off-by:
John Pittman <jpittman@redhat.com> Signed-off-by:
-
Martin Wilck authored
rport_dev_loss_timedout() sets the rport state to SRP_PORT_LOST and the SCSI target state to SDEV_TRANSPORT_OFFLINE. If this races with srp_reconnect_work(), a warning is printed: Mar 27 18:48:07 ictm1604s01h4 kernel: dev_loss_tmo expired for SRP port-18:1 / host18. Mar 27 18:48:07 ictm1604s01h4 kernel: ------------[ cut here ]------------ Mar 27 18:48:07 ictm1604s01h4 kernel: scsi_internal_device_block(18:0:0:100) failed: ret = -22 Mar 27 18:48:07 ictm1604s01h4 kernel: Call Trace: Mar 27 18:48:07 ictm1604s01h4 kernel: ? scsi_target_unblock+0x50/0x50 [scsi_mod] Mar 27 18:48:07 ictm1604s01h4 kernel: starget_for_each_device+0x80/0xb0 [scsi_mod] Mar 27 18:48:07 ictm1604s01h4 kernel: target_block+0x24/0x30 [scsi_mod] Mar 27 18:48:07 ictm1604s01h4 kernel: device_for_each_child+0x57/0x90 Mar 27 18:48:07 ictm1604s01h4 kernel: srp_reconnect_rport+0xe4/0x230 [scsi_transport_srp] Mar 27 18:48:07 ictm1604s01h4 kernel: srp_reconnect_work+0x40/0xc0 [scsi_transport_srp] Avoid this by not trying to block targets for rports in SRP_PORT_LOST state. Link: https://lore.kernel.org/r/20210401091105.8046-1-mwilck@suse.comReviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin Wilck <mwilck@suse.com> Signed-off-by:
-
Roman Bolshakov authored
target_sequencer_start event is triggered inside target_cmd_init_cdb(). se_cmd.tag is not initialized with ITT at the moment so the event always prints zero tag. Link: https://lore.kernel.org/r/20210403215415.95077-1-r.bolshakov@yadro.com Cc: stable@vger.kernel.org # 5.10+ Reviewed-by:
-
Viswas G authored
Inbound and outbound queues were not properly configured and that lead to MPI configuration failure. Fixes: 05c6c029 ("scsi: pm80xx: Increase number of supported queues") Cc: stable@vger.kernel.org # 5.10+ Link: https://lore.kernel.org/r/20210402054212.17834-1-Viswas.G@microchip.com.comReported-and-tested-by:
Ash Izat <ash@ai0.uk> Signed-off-by:
Viswas G <Viswas.G@microchip.com> Signed-off-by:
-
Don Brace authored
Update version. Link: https://lore.kernel.org/r/161549387469.25025.12859568843576080076.stgit@brunhildaReviewed-by:
Scott Benesh <scott.benesh@microchip.com> Reviewed-by:
Gerry Morong <gerry.morong@microchip.com> Reviewed-by:
Mike McGowen <mike.mcgowen@microchip.com> Reviewed-by:
Scott Teel <scott.teel@microchip.com> Reviewed-by:
Kevin Barnett <kevin.barnett@microchip.com> Reviewed-by:
Don Brace <don.brace@microchip.com> Signed-off-by:
-
