- 07 Mar, 2019 3 commits
-
-
Bill Kuzeja authored
When trying to display tgt_counters in the debugfs, a panic can result. There is no null check for qpair after it is assigned in the for-loop. Unless vha->hw->queue_pair_map array is completely filled with entries, the system will panic dereferencing a null pointer. Signed-off-by:
Bill Kuzeja <william.kuzeja@stratus.com> Acked-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Steve Sistare authored
megaraid_sas takes 1+ seconds to load while waiting for firmware: [2.822603] megaraid_sas 0000:03:00.0: Waiting for FW to come to ready state [3.871003] megaraid_sas 0000:03:00.0: FW now in Ready state This is due to the following loop in megasas_transition_to_ready(), which waits a minimum of 1 second, even though the FW becomes ready in tens of millisecs: /* * The cur_state should not last for more than max_wait secs */ for (i = 0; i < max_wait; i++) { ... msleep(1000); ... dev_info(&instance->pdev->dev, "FW now in Ready state\n"); This is a regression, caused by a change of the msleep granularity from 1 to 1000 due to concern about waiting too long on systems with coarse jiffies. To fix, increase iterations and use msleep(20), which results in: [2.670627] megaraid_sas 0000:03:00.0: Waiting for FW to come to ready state [2.739386] megaraid_sas 0000:03:00.0: FW now in Ready state Fixes: fb2f3e96d80f ("scsi: megaraid_sas: Fix msleep granularity") Signed-off-by:
Steve Sistare <steven.sistare@oracle.com> Acked-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Cathy Avery authored
genlmsg_multicast_allns now returns the correct statuses when a message is sent to a listener. However in the case of adding a device we want to wait for the listener otherwise we may miss the the device during startup. Signed-off-by:
Cathy Avery <cavery@redhat.com> Acked-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 06 Mar, 2019 2 commits
-
-
Felipe Franciosi authored
The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of device-readable records and a single device-writable response entry: struct virtio_scsi_ctrl_tmf { // Device-readable part le32 type; le32 subtype; u8 lun[8]; le64 id; // Device-writable part u8 response; } The above should be organised as two descriptor entries (or potentially more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after "le64 id" or after "u8 response". The Linux driver doesn't respect that, with virtscsi_abort() and virtscsi_device_reset() setting cmd->sc before calling virtscsi_tmf(). It results in the original scsi command payload (or writable buffers) added to the tmf. This fixes the problem by leaving cmd->sc zeroed out, which makes virtscsi_kick_cmd() add the tmf to the control vq without any payload. Cc: stable@vger.kernel.org Signed-off-by:
Felipe Franciosi <felipe@nutanix.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Erwan Velu authored
When the HARDWARE_ERROR/0x3e/0x1 case is triggered, the logical volume is offlined. When reading the kernel log, the reason why the device got offlined isn't reported to the user. This situation makes it difficult for admins to root cause. Log a message when this condition occurs. [mkp: tweaked commit message] Signed-off-by:
Erwan Velu <e.velu@criteo.com> Acked-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 27 Feb, 2019 15 commits
-
-
Varun Prakash authored
T6 adapters generates DDP completion message on receiving all iSCSI pdus in a sequence. Because of this, driver can not keep track of tcp sequence number for T6 adapters. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Varun Prakash authored
Instead of using viid to get pf number, directly get pf number from lldi->pf. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Benjamin Block authored
We had a test-report where, under memory pressure, adding LUNs to the systems would fail (the tests add LUNs strictly in sequence): [ 5525.853432] scsi 0:0:1:1088045124: Direct-Access IBM 2107900 .148 PQ: 0 ANSI: 5 [ 5525.853826] scsi 0:0:1:1088045124: alua: supports implicit TPGS [ 5525.853830] scsi 0:0:1:1088045124: alua: device naa.6005076303ffd32700000000000044da port group 0 rel port 43 [ 5525.853931] sd 0:0:1:1088045124: Attached scsi generic sg10 type 0 [ 5525.854075] sd 0:0:1:1088045124: [sdk] Disabling DIF Type 1 protection [ 5525.855495] sd 0:0:1:1088045124: [sdk] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB) [ 5525.855606] sd 0:0:1:1088045124: [sdk] Write Protect is off [ 5525.855609] sd 0:0:1:1088045124: [sdk] Mode Sense: ed 00 00 08 [ 5525.855795] sd 0:0:1:1088045124: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5525.857838] sdk: sdk1 [ 5525.859468] sd 0:0:1:1088045124: [sdk] Attached SCSI disk [ 5525.865073] sd 0:0:1:1088045124: alua: transition timeout set to 60 seconds [ 5525.865078] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA [ 5526.015070] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA [ 5526.015213] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA [ 5526.587439] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured [ 5526.588562] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured Looking at the code of scsi_alloc_sdev(), and all the calling contexts, there seems to be no reason to use GFP_ATMOIC here. All the different call-contexts use a mutex at some point, and nothing in between that requires no sleeping, as far as I could see. Additionally, the code that later allocates the block queue for the device (scsi_mq_alloc_queue()) already uses GFP_KERNEL. There are similar allocations in two other functions: scsi_probe_and_add_lun(), and scsi_add_lun(),; that can also be done with GFP_KERNEL. Here is the contexts for the three functions so far: scsi_alloc_sdev() scsi_probe_and_add_lun() scsi_sequential_lun_scan() __scsi_scan_target() scsi_scan_target() mutex_lock() scsi_scan_channel() scsi_scan_host_selected() mutex_lock() scsi_report_lun_scan() __scsi_scan_target() ... __scsi_add_device() mutex_lock() __scsi_scan_target() ... scsi_report_lun_scan() ... scsi_get_host_dev() mutex_lock() scsi_probe_and_add_lun() ... scsi_add_lun() scsi_probe_and_add_lun() ... So replace all these, and give them a bit of a better chance to succeed, with more chances of reclaim. Signed-off-by:
Benjamin Block <bblock@linux.ibm.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Gustavo A. R. Silva authored
Fix the following warnings by adding the proper missing breaks: drivers/scsi/mpt3sas/mpt3sas_base.c: In function _base_display_OEMs_branding : drivers/scsi/mpt3sas/mpt3sas_base.c:3548:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (ioc->pdev->subsystem_device) { ^~~~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3566:3: note: here case MPI2_MFGPAGE_DEVID_SAS2308_2: ^~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3567:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (ioc->pdev->subsystem_device) { ^~~~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3601:3: note: here case MPI25_MFGPAGE_DEVID_SAS3008: ^~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3735:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (ioc->pdev->subsystem_device) { ^~~~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3745:3: note: here case MPI2_MFGPAGE_DEVID_SAS2308_2: ^~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3746:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (ioc->pdev->subsystem_device) { ^~~~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3768:3: note: here default: ^~~~~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Gustavo A. R. Silva authored
Add missing break statement and fix identation issue. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: 9cb62fa2 ("aacraid: Log firmware AIF messages") Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hannes Reinecke authored
No users left, kill it. Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hannes Reinecke authored
Use request tag instead of the serial number when printing out logging messages. Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hannes Reinecke authored
Use the request tag for logging instead of the scsi command serial number. Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hannes Reinecke authored
Drop references to scsi_cmnd->serial_number. Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Iustin Pop authored
Negative constant left-shift is undefined behaviour in the C standard, and as such newer versions of clang (at least) warn against it. GCC supports it for a long time, but it would be better to remove it and rely on defined behaviour. My understanding is "~(-1 << N)" in 2's complement is intended to generate a bit pattern of zeroes ending with N '1' bits. The same can be achieved by "(1 << N) - 1" in a well-defined way, so switch to it to remove the warning. Tested: building a kernel with generic SCSI tape, and checking basic operations (mt status, mt eject) on a real LTO unit. Cannot test the osst driver. Signed-off-by:
Iustin Pop <iustin@k1024.org> Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Avri Altman authored
Add this functionality, placing the descriptor being read in the actual data buffer in the bio. That is, for both read and write descriptors query upiu, we are using the job's request_payload. This in turn, is mapped back in user land to the applicable sg_io_v4 xferp: dout_xferp for write descriptor, and din_xferp for read descriptor. Signed-off-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Avri Altman authored
Allow to read descriptors via raw upiu. This in fact was forbidden just as a precaution, as ufs-bsg actually enforces which functionality is supported. Signed-off-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Avri Altman authored
When we had a write descriptor query upiu, we appended the descriptor right after the bsg request. This was fine as the bsg driver allows to allocate whatever buffer we needed in its job request. Still, the proper way to deliver payload, however small (we only write config descriptors of 144 bytes), is by using the job request payload data buffer. So change this ABI now, while ufs-bsg is still new, and nobody is actually using it. Signed-off-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Marc Gonzalez authored
The UFSHC driver defines a few quirks that are not used anywhere: UFS_DEVICE_QUIRK_BROKEN_LCC UFS_DEVICE_NO_VCCQ UFS_DEVICE_QUIRK_NO_LINK_OFF UFS_DEVICE_NO_FASTAUTO Let's remove them. Acked-by:
Avri Altman <avri.altman@wdc.com> Acked-by:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Signed-off-by:
Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Marc Gonzalez authored
This reverts commit 60f01870. There was one conflict in drivers/scsi/ufs/ufshcd.c <<<<<<< HEAD /* Init check for device descriptor sizes */ ufshcd_init_desc_sizes(hba); ret = ufs_get_device_desc(hba, &card); if (ret) { dev_err(hba->dev, "%s: Failed getting device info. err = %d\n", __func__, ret); goto out; } ufs_fixup_device_setup(hba, &card); ufshcd_tune_unipro_params(hba); ret = ufshcd_set_vccq_rail_unused(hba, (hba->dev_quirks & UFS_DEVICE_NO_VCCQ) ? true : false); if (ret) goto out; ======= ufs_advertise_fixup_device(hba); >>>>>>> parent of 60f01870... scsi: ufs: disable vccq if it's not needed by UFS device Resolution: keep HEAD, and delete the ufshcd_set_vccq_rail_unused() call and corresponding error-handling code. Clean up loose ends in a follow-up patch. 60f01870 introduced a small power optimization: ignore the vccq load specified in the UFSHC DT node when said host controller is connected to specific Flash chips (currently, Samsung and Hynix). Unfortunately, this optimization breaks UFS on systems where vccq powers not only the Flash chip, but the host controller as well, such as APQ8098 MEDIABOX or MTP8998: [ 3.929877] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 for idn 13 failed, index 0, err = -11 [ 5.433815] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 for idn 13 failed, index 0, err = -11 [ 6.937771] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 for idn 13 failed, index 0, err = -11 [ 6.937866] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr_retry: query attribute, idn 13, failed with error -11 after 3 retires [ 6.946412] ufshcd-qcom 1da4000.ufshc: ufshcd_disable_auto_bkops: failed to enable exception event -11 [ 6.957972] ufshcd-qcom 1da4000.ufshc: dme-peer-get: attr-id 0x1587 failed 3 retries [ 6.967181] ufshcd-qcom 1da4000.ufshc: dme-peer-get: attr-id 0x1586 failed 3 retries [ 6.975025] ufshcd-qcom 1da4000.ufshc: ufshcd_get_max_pwr_mode: invalid max pwm tx gear read = 0 [ 6.982755] ufshcd-qcom 1da4000.ufshc: ufshcd_probe_hba: Failed getting max supported power mode [ 8.505770] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [ 10.009807] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [ 11.513766] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [ 11.513861] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag_retry: query attribute, opcode 5, idn 3, failed with error -11 after 3 retires [ 13.049807] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode 0x01 for idn 8 failed, index 0, err = -11 [ 14.553768] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode 0x01 for idn 8 failed, index 0, err = -11 [ 16.057767] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode 0x01 for idn 8 failed, index 0, err = -11 [ 16.057872] ufshcd-qcom 1da4000.ufshc: ufshcd_read_desc_param: Failed reading descriptor. desc_id 8, desc_index 0, param_offset 0, ret -11 [ 16.067109] ufshcd-qcom 1da4000.ufshc: ufshcd_init_icc_levels: Failed reading power descriptor.len = 98 ret = -11 [ 37.073787] ufshcd-qcom 1da4000.ufshc: link startup failed 1 In my opinion, the rationale for the original patch is questionable. If neither the UFSHC, nor the Flash chip, require any load from vccq, then that power rail should simply not be specified at all in the DT. Working around that fact in the driver is detrimental, as evidenced by the failure to initialize the host controller on MSM8998. Acked-by:
Avri Altman <avri.altman@wdc.com> Acked-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 26 Feb, 2019 4 commits
-
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'wait_and_poll': drivers/scsi/megaraid/megaraid_sas_fusion.c:936:25: warning: variable 'fusion' set but not used [-Wunused-but-set-variable] drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_sync_map_info': drivers/scsi/megaraid/megaraid_sas_fusion.c:1329:6: warning: variable 'size_sync_info' set but not used [-Wunused-but-set-variable] drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_init_adapter_fusion': drivers/scsi/megaraid/megaraid_sas_fusion.c:1639:39: warning: variable 'reg_set' set but not used [-Wunused-but-set-variable] drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_is_prp_possible': drivers/scsi/megaraid/megaraid_sas_fusion.c:1925:25: warning: variable 'fusion' set but not used [-Wunused-but-set-variable] drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_make_prp_nvme': drivers/scsi/megaraid/megaraid_sas_fusion.c:2047:25: warning: variable 'fusion' set but not used [-Wunused-but-set-variable] drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_build_ldio_fusion': drivers/scsi/megaraid/megaraid_sas_fusion.c:2620:42: warning: variable 'req_desc' set but not used [-Wunused-but-set-variable] drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_build_and_issue_cmd_fusion': drivers/scsi/megaraid/megaraid_sas_fusion.c:3245:25: warning: variable 'fusion' set but not used [-Wunused-but-set-variable] drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_task_abort_fusion': drivers/scsi/megaraid/megaraid_sas_fusion.c:4398:25: warning: variable 'fusion' set but not used [-Wunused-but-set-variable] drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_reset_target_fusion': drivers/scsi/megaraid/megaraid_sas_fusion.c:4484:25: warning: variable 'fusion' set but not used [-Wunused-but-set-variable] They're not used anymore and can be removed. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Avri Altman authored
Those are no longer in use since commit 242f9dcb ("block: unify request timeout handling"). Signed-off-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Martin K. Petersen authored
It was reported that some devices report an OPTIMAL TRANSFER LENGTH of 0xFFFF blocks. That looks bogus, especially for a device with a 4096-byte physical block size. Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's reported physical block size. To make the sanity checking conditionals more readable--and to facilitate printing warnings--relocate the checking to a helper function. No functional change aside from the printks. Cc: <stable@vger.kernel.org> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759Reported-by:
Christoph Anton Mitterer <calestyo@scientia.net> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Martin K. Petersen authored
Nic has been absent for a while and target changes now go through the SCSI tree. To avoid confusion wrt. the NVMe target, clarify that this entry refers to the SCSI target subsystem. Also add patchwork links for both SCSI initiator and target. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 19 Feb, 2019 16 commits
-
-
Sedat Dilek authored
commit 1917d42d ("fcoe: use enum for fip_mode") introduces a separate enum for the fip_mode that shall be used during initialisation handling until it is passed to fcoe_ctrl_link_up to set the initial fip_state. That change was incomplete and gcc quietly converted in various places between the fip_mode and the fip_state enum values with implicit enum conversions, which fortunately cannot cause any issues in the actual code's execution. clang however warns about these implicit enum conversions in the scsi drivers. This commit consolidates the use of the two enums, guided by clang's enum-conversion warnings. This commit now completes the use of the fip_mode: It expects and uses fip_mode in {bnx2fc,fcoe}_interface_create and fcoe_ctlr_init, and it calls fcoe_ctrl_set_set() with the correct values in fcoe_ctlr_link_up(). It also breaks the association between FIP_MODE_AUTO and FIP_ST_AUTO to indicate these two enums are distinct. Link: https://github.com/ClangBuiltLinux/linux/issues/151 Fixes: 1917d42d ("fcoe: use enum for fip_mode") Reported-by:
Dmitry Golovin <dima@golovin.in> Original-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> CC: Lukas Bulwahn <lukas.bulwahn@gmail.com> CC: Nick Desaulniers <ndesaulniers@google.com> CC: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Tested-by:
Nathan Chancellor <natechancellor@gmail.com> Suggested-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Jason Yan authored
when create DMA pool for cmd frames failed, we should return -ENOMEM, instead of 0. In some case in: megasas_init_adapter_fusion() -->megasas_alloc_cmds() -->megasas_create_frame_pool create DMA pool failed, --> megasas_free_cmds() [1] -->megasas_alloc_cmds_fusion() failed, then goto fail_alloc_cmds. -->megasas_free_cmds() [2] we will call megasas_free_cmds twice, [1] will kfree cmd_list, [2] will use cmd_list.it will cause a problem: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc000f70000 [00000000] *pgd=0000001fbf893003, *pud=0000001fbf893003, *pmd=0000001fbf894003, *pte=006000006d000707 Internal error: Oops: 96000005 [#1] SMP Modules linked in: CPU: 18 PID: 1 Comm: swapper/0 Not tainted task: ffffffdfb9290000 ti: ffffffdfb923c000 task.ti: ffffffdfb923c000 PC is at megasas_free_cmds+0x30/0x70 LR is at megasas_free_cmds+0x24/0x70 ... Call trace: [<ffffffc0005b779c>] megasas_free_cmds+0x30/0x70 [<ffffffc0005bca74>] megasas_init_adapter_fusion+0x2f4/0x4d8 [<ffffffc0005b926c>] megasas_init_fw+0x2dc/0x760 [<ffffffc0005b9ab0>] megasas_probe_one+0x3c0/0xcd8 [<ffffffc0004a5abc>] local_pci_probe+0x4c/0xb4 [<ffffffc0004a5c40>] pci_device_probe+0x11c/0x14c [<ffffffc00053a5e4>] driver_probe_device+0x1ec/0x430 [<ffffffc00053a92c>] __driver_attach+0xa8/0xb0 [<ffffffc000538178>] bus_for_each_dev+0x74/0xc8 [<ffffffc000539e88>] driver_attach+0x28/0x34 [<ffffffc000539a18>] bus_add_driver+0x16c/0x248 [<ffffffc00053b234>] driver_register+0x6c/0x138 [<ffffffc0004a5350>] __pci_register_driver+0x5c/0x6c [<ffffffc000ce3868>] megasas_init+0xc0/0x1a8 [<ffffffc000082a58>] do_one_initcall+0xe8/0x1ec [<ffffffc000ca7be8>] kernel_init_freeable+0x1c8/0x284 [<ffffffc0008d90b8>] kernel_init+0x1c/0xe4 Signed-off-by:
Jason Yan <yanaijie@huawei.com> Acked-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Giridhar Malavali authored
This patch fixes warning seen when BLK-MQ is enabled and hardware does not support MQ. This will result into driver requesting MSIx vectors which are equal or less than pre_desc via PCI IRQ Affinity infrastructure. [ 19.746300] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 10.00.00.12-k. [ 19.746599] qla2xxx [0000:02:00.0]-001d: : Found an ISP2432 irq 18 iobase 0x(____ptrval____). [ 20.203186] ------------[ cut here ]------------ [ 20.203306] WARNING: CPU: 8 PID: 268 at drivers/pci/msi.c:1273 pci_irq_get_affinity+0xf4/0x120 [ 20.203481] Modules linked in: tg3 ptp qla2xxx(+) pps_core sg libphy scsi_transport_fc flash loop autofs4 [ 20.203700] CPU: 8 PID: 268 Comm: systemd-udevd Not tainted 5.0.0-rc5-00358-gdf3865f8 #113 [ 20.203830] Call Trace: [ 20.203933] [0000000000461bb0] __warn+0xb0/0xe0 [ 20.204090] [00000000006c8f34] pci_irq_get_affinity+0xf4/0x120 [ 20.204219] [000000000068c764] blk_mq_pci_map_queues+0x24/0x120 [ 20.204396] [00000000007162f4] scsi_map_queues+0x14/0x40 [ 20.204626] [0000000000673654] blk_mq_update_queue_map+0x94/0xe0 [ 20.204698] [0000000000676ce0] blk_mq_alloc_tag_set+0x120/0x300 [ 20.204869] [000000000071077c] scsi_add_host_with_dma+0x7c/0x300 [ 20.205419] [00000000100ead54] qla2x00_probe_one+0x19d4/0x2640 [qla2xxx] [ 20.205621] [00000000006b3c88] pci_device_probe+0xc8/0x160 [ 20.205697] [0000000000701c0c] really_probe+0x1ac/0x2e0 [ 20.205770] [0000000000701f90] driver_probe_device+0x50/0x100 [ 20.205843] [0000000000702134] __driver_attach+0xf4/0x120 [ 20.205913] [0000000000700644] bus_for_each_dev+0x44/0x80 [ 20.206081] [0000000000700c98] bus_add_driver+0x198/0x220 [ 20.206300] [0000000000702950] driver_register+0x70/0x120 [ 20.206582] [0000000010248224] qla2x00_module_init+0x224/0x284 [qla2xxx] [ 20.206857] ---[ end trace b1de7a3f79fab2c2 ]--- The fix is to check if the hardware does not have Multi Queue capabiltiy, use pci_alloc_irq_vectors() call instead of pci_alloc_irq_affinity(). Fixes: f664a3cc ("scsi: kill off the legacy IO path") Cc: stable@vger.kernel.org #4.19 Signed-off-by:
Giridhar Malavali <gmalavali@marvell.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Himanshu Madhani authored
Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Joe Carnuccio authored
This patch adds new firmware dump template entries for ISP27XX firmware dump. Signed-off-by:
Joe Carnuccio <joe.carnuccio@cavium.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Himanshu Madhani authored
This patch fixes following checkpatch ERROR ERROR: space prohibited before that ',' (ctx:WxW) No change is functionality due to this patch. Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Quinn Tran authored
Current code hard codes marker request to use request and response queue 0. This patch make use of the qpair as the path to access the request/response queues. It allows marker to be place on any hardware queue. Signed-off-by:
Quinn Tran <qtran@marvell.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Quinn Tran authored
Prevent user from sending commands through sysfs while FW is not running or reset is in progress. Signed-off-by:
Quinn Tran <qtran@marvell.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Anil Gurumurthy authored
This patch adds sysfs node 1. There is a new sysfs node port_speed 2. The possible values are 2(Auto neg), 8, 16, 32 3. A value outside of the above defaults to Auto neg 4. Any update to the setting causes a link toggle 5. This feature is currently only for ISP27xx Signed-off-by:
Anil Gurumurthy <agurumurthy@marvell.com> Signed-off-by:
Quinn Tran <qtran@marvell.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Quinn Tran authored
Add check to allow 1 discovery command per session to be sent. Signed-off-by:
Quinn Tran <qtran@marvell.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Himanshu Madhani authored
For FC-NVMe, if the fw_started flag is not set or fcport is deleted, then do not send Abort command Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Himanshu Madhani authored
This patch fixes driver unload issue when FC-NVMe devices are configured. Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Darren Trapp authored
Add Support for First Burst for FC-NVMe protocol. This feature requires First Burst support in the firmware. Signed-off-by:
Darren Trapp <darren.trapp@cavium.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Himanshu Madhani authored
This patch fixes LUN discovery when loop ID is not yet assigned by the firmware during driver load/sg_reset operations. Driver will now search for new loop id before retrying login. Fixes: 48acad09 ("scsi: qla2xxx: Fix N2N link re-connect") Cc: stable@vger.kernel.org #4.19 Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Colin Ian King authored
The null check on pointer sess and the subsequent call is redundant as sess is null on all the the paths that lead to the out_term2 label. Hence the null check and the call can be removed. Also remove the redundant setting of sess to NULL as this is not required now. Detected by CoverityScan, CID#1420663 ("Logically dead code") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Bill Kuzeja authored
When sending an srb with qla2x00_start_sp, the sp can complete and be freed by the time we log the debug message saying we sent it. This can cause a panic if sp gets reused quickly or when running a kernel that poisons freed memory. This was partially fixed by (not every case was addressed): Commit 9fe278f4 ("scsi: qla2xxx: Move log messages before issuing command to firmware") Signed-off-by:
Bill Kuzeja <william.kuzeja@stratus.com> Acked-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-