- 12 May, 2020 19 commits
-
-
Sumit Saxena authored
When TM command times out, driver invokes the controller reset. Post reset, driver re-fires pended TM commands which leads to firmware crash. Post controller reset, return pended TM commands back to OS. Link: https://lore.kernel.org/r/20200508085242.23406-1-chandrakanth.patil@broadcom.com Cc: stable@vger.kernel.org Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
Chandrakanth Patil <chandrakanth.patil@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Shivasharan S authored
MFI_BIG_ENDIAN macro used in drivers structure bitfield to check the CPU big endianness is undefined which would break the code on big endian machine. __BIG_ENDIAN_BITFIELD kernel macro should be used in places of MFI_BIG_ENDIAN macro. Link: https://lore.kernel.org/r/20200508085130.23339-1-chandrakanth.patil@broadcom.com Fixes: a7faf81d ("scsi: megaraid_sas: Set no_write_same only for Virtual Disk") Cc: <stable@vger.kernel.org> # v5.6+ Signed-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by:
-
Sumit Saxena authored
As blk_queue_virt_boundary() API in slave_configure ensures that no IOs will come with holes/gaps. Hence, code logic to detect the holes/gaps in IO buffer is not required. Link: https://lore.kernel.org/r/20200508083838.22778-3-chandrakanth.patil@broadcom.comSigned-off-by:
-
Kashyap Desai authored
The driver currently assigns a pre-defined queue depth when the firmware-provided device queue depth is greater than the controller queue depth. Use the controller queue depth if the reported target queue depth is too large. Link: https://lore.kernel.org/r/20200508083838.22778-2-chandrakanth.patil@broadcom.comSigned-off-by:
Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by:
-
Stanley Chu authored
Small cleanup as below items, 1. Use ufshcd_is_wb_allowed() directly instead of ufshcd_wb_sup() since ufshcd_wb_sup() just returns the result of ufshcd_is_wb_allowed(). 2. In ufshcd_suspend(), "else if (!ufshcd_is_runtime_pm(pm_op)) can be simplified to "else" since both have the same meaning. This patch does not change any functionality. Link: https://lore.kernel.org/r/20200508080115.24233-9-stanley.chu@mediatek.comReviewed-by:Avri Altman <avri.altman@wdc.com> Reviewed-by:
Asutosh Das <asutoshd@codeaurora.org> Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
-
Stanley Chu authored
Enable WriteBooster capability on MediaTek UFS platforms. Link: https://lore.kernel.org/r/20200508080115.24233-8-stanley.chu@mediatek.comReviewed-by:
Bean Huo <beanhuo@micron.com> Reviewed-by:
-
Stanley Chu authored
According to UFS specification, there are two WriteBooster mode of operations: "LU dedicated buffer" mode and "shared buffer" mode. In the "LU dedicated buffer" mode, the WriteBooster Buffer is dedicated to a logical unit. If the device supports the "LU dedicated buffer" mode, this mode is configured by setting bWriteBoosterBufferType to 00h. The logical unit WriteBooster Buffer size is configured by setting the dLUNumWriteBoosterBufferAllocUnits field of the related Unit Descriptor. Only a value greater than zero enables the WriteBooster feature in the logical unit. Modify ufshcd_wb_probe() as above description to support LU Dedicated buffer mode. Note that according to UFS 3.1 specification, the valid value of bDeviceMaxWriteBoosterLUs parameter in Geometry Descriptor is 1, which means at most one LUN can have WriteBooster buffer in "LU dedicated buffer mode". Therefore this patch supports only one LUN with WriteBooster enabled. All WriteBooster related sysfs nodes are specifically mapped to the LUN with WriteBooster enabled in LU Dedicated buffer mode. Link: https://lore.kernel.org/r/20200508080115.24233-7-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
For preparation of LU Dedicated buffer mode support on WriteBooster feature, "index" parameter shall be added and allowed to be specified by callers. Link: https://lore.kernel.org/r/20200508080115.24233-6-stanley.chu@mediatek.comReviewed-by:
Can Guo <cang@codeaurora.org> Reviewed-by:
-
Stanley Chu authored
Add fixup_dev_quirk vops in MediaTek UFS platforms and provide an initial vendor-specific device quirk table. Link: https://lore.kernel.org/r/20200508080115.24233-5-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Export ufs_fixup_device_setup() to allow vendors to re-use it for fixing device quriks on specified UFS hosts. Link: https://lore.kernel.org/r/20200508080115.24233-4-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Some UFS deivces may have required device quirks or have non-standard features which are enabled only on specified UFS hosts or for special customers. To not "pollute" common device quirk list, i.e. ufs_fixups table, for those devices mentioned above, introduce "fixup_dev_quirks" vops to allow vendors to fix or modify device quirks accordingly. Link: https://lore.kernel.org/r/20200508080115.24233-3-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
The WriteBooster feature can be supported by some pre-3.1 UFS devices by upgrading firmware. To enable WriteBooster feature in such devices, introduce a device quirk to relax the entrance condition of ufshcd_wb_probe() to allow host driver to check those devices' WriteBooster capability. WriteBooster feature can be available if below all conditions are satisfied, 1. Host enables WriteBooster capability 2. UFS 3.1 device or UFS pre-3.1 device with quirk UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES enabled 3. The device descriptor shall have DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP field 4. WriteBooster support is specified in above field Link: https://lore.kernel.org/r/20200508080115.24233-2-stanley.chu@mediatek.comReviewed-by: -
Colin Ian King authored
The variable rc is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Link: https://lore.kernel.org/r/20200507203111.64709-1-colin.king@canonical.comSigned-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Link: https://lore.kernel.org/r/20200507192550.GA16683@embeddedorSigned-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Link: https://lore.kernel.org/r/20200507192147.GA16206@embeddedorReviewed-by:John Garry <john.garry@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
Xie XiuQi authored
uctrl and udev are unused after commit 9632a6b4 ("scsi: qedi: Move LL2 producer index processing in BH.") Remove them. Link: https://lore.kernel.org/r/20200505121904.25702-1-xiexiuqi@huawei.comReviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
-
Jason Yan authored
Fix the following sparse warning: drivers/scsi/bfa/bfad_bsg.c:140:1: warning: symbol 'bfad_iocmd_ioc_get_stats' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200505073807.40332-1-yanaijie@huawei.comReported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
-
Bodo Stroesser authored
We use tcm_loop with tape emulations running on tcmu. In case application reads a short tape block with a longer READ, or a long tape block with a short READ, according to SCC spec data has to be tranferred _and_ sensebytes with ILI set and information field containing the residual count. Similar problem also exists when using fixed block size in READ. Up to now tcm_loop is not prepared to handle sensebytes if input data is provided, as in tcm_loop_queue_data_in() it only sets SAM_STAT_GOOD and, if necessary, the residual count. To fix the bug, the same handling for sensebytes as present in tcm_loop_queue_status() must be done in tcm_loop_queue_data_in() also. After adding this handling, the two function now are nearly identical, so I created a single function with two wrappers. Link: https://lore.kernel.org/r/20200428182617.32726-1-bstroesser@ts.fujitsu.comSigned-off-by:
Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by:
-
Zou Wei authored
Fix coccicheck warning which recommends to use memdup_user(). This patch fixes the following coccicheck warning: drivers/scsi/aacraid/commctrl.c:516:15-22: WARNING opportunity for memdup_user Link: https://lore.kernel.org/r/1587868964-75969-1-git-send-email-zou_wei@huawei.com Fixes: 4645df10 ("[PATCH] aacraid: swapped kmalloc args.") Reported-by:
Zou Wei <zou_wei@huawei.com> Signed-off-by:
-
- 08 May, 2020 21 commits
-
-
Dick Kennedy authored
Update lpfc version to 12.8.0.1 Link: https://lore.kernel.org/r/20200501214310.91713-10-jsmart2021@gmail.comReviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
Dick Kennedy authored
The MDS diagnostic enablement bit for the adapter interface is incorrect in the driver header. Correct the bit position for the SET_FEATURE MDS bit. Link: https://lore.kernel.org/r/20200501214310.91713-9-jsmart2021@gmail.comReviewed-by:
-
Dick Kennedy authored
Running make C=1 M=drivers/scsi/lpfc triggers sparse warnings Correct the code generating the following errors: - Incompatible address space assignment without proper conversion. - Deference of usespace and per-cpu pointers. Link: https://lore.kernel.org/r/20200501214310.91713-8-jsmart2021@gmail.comReviewed-by:
-
Dick Kennedy authored
In an audit of lockdep calls in the driver, there are multiple lockdep checks in successive calling layers. E.g. a routine checks, and then calls a lower routine that also checks, and so on. Calling sequences result in many redundant checks. Refine the code to remove lower-level lockdep checks. Update comments on the lock, correcting a few places where lock object in comment was incorrect. Link: https://lore.kernel.org/r/20200501214310.91713-7-jsmart2021@gmail.comReviewed-by:
-
Dick Kennedy authored
By default, the driver attempts to allocate a hdwq per logical cpu in order to provide good cpu affinity. Some systems have extremely high cpu counts and this can significantly raise memory consumption. In testing on x86 platforms (non-AMD) it is found that sharing of a hdwq by a physical cpu and its HT cpu can occur with little performance degredation. By sharing, the hdwq count can be halved, significantly reducing the memory overhead. Change the default behavior of the driver on non-AMD x86 platforms to share a hdwq by the cpu and its HT cpu. Link: https://lore.kernel.org/r/20200501214310.91713-6-jsmart2021@gmail.comReviewed-by:
-
Dick Kennedy authored
Implementation of a previous patch added a condition to an if check that always end up with the if test being true. Execution of the else clause was inadvertently negated. The additional condition check was incorrect and unnecessary after the other modifications had been done in that patch. Remove the check from the if series. Link: https://lore.kernel.org/r/20200501214310.91713-5-jsmart2021@gmail.com Fixes: b95b2119 ("scsi: lpfc: Fix loss of remote port after devloss due to lack of RPIs") Cc: <stable@vger.kernel.org> # v5.4+ Reviewed-by:
-
Dick Kennedy authored
The lldd rebinds the ndlp with rport during a nvme rport registration (via nvme_fc_register_remoteport). If rport & ndlp pointers are same as the previous one, the lldd will re-use the ndlp and rport association without re-initialization. This assumption is incorrect. The lldd should be ignorant of whether the returned rport pointer is new or not, and should always assume it is new. Remove the re-binding code, always assumes that rport pointer received from transport is a new pointer. Link: https://lore.kernel.org/r/20200501214310.91713-4-jsmart2021@gmail.comReviewed-by:
-
Dick Kennedy authored
A previous change introduced the atomic use of queue_claimed flag for eq's and cq's. The code works fine, but the clearing of the queue_claimed flag is not atomic. Change queue_claimed = 0 into xchg(&queue_claimed, 0) to be consistent for change under atomicity. Link: https://lore.kernel.org/r/20200501214310.91713-3-jsmart2021@gmail.comReviewed-by:
-
Bodo Stroesser authored
Currently in tcmu reservation commands are handled by core's pr implementation (default) or completely rejected (emulate_pr set to 0). We additionally want to be able to do full reservation handling in userspace. Therefore we need a way to set TRANSPORT_FLAG_PASSTHROUGH_PGR. The inverted flag is displayed by attribute pgr_support. Since we moved the flag from transport/backend to se_device in the previous commit, we now can make it changeable per device by allowing to write the attribute. The new field transport_flags_changeable in transport/backend is used to reject writing if not allowed for a backend. Regarding ALUA we also want to be able to passthrough commands to userspace in tcmu. Therefore we need TRANSPORT_FLAG_PASSTHROUGH_ALUA to be changeable, because by setting it we can switch off all ALUA checks in core. So we also set TRANSPORT_FLAG_PASSTHROUGH_ALUA in tcmu's transport_flags_changeable. Of course, ALUA and reservation handling in userspace will work only, if session/nexus information is sent to userspace along with every command. This will be object of a patch series announced by Mike Christie. Link: https://lore.kernel.org/r/20200427150823.15350-5-bstroesser@ts.fujitsu.comReviewed-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
-
Bodo Stroesser authored
pgr_support and alua_support device attributes show the inverted value of the transport_flags: * TRANSPORT_FLAG_PASSTHROUGH_PGR * TRANSPORT_FLAG_PASSTHROUGH_ALUA These attributes are per device, while the flags are per backend. Rename the transport_flags in backend/transport to transport_flags_default and use this value to initialize the new transport_flags field in the se_device structure. Now data and attribute both are per se_device. Link: https://lore.kernel.org/r/20200427150823.15350-4-bstroesser@ts.fujitsu.comReviewed-by:
-
Bodo Stroesser authored
tcmu has not set TRANSPORT_FLAG_PASSTHROUGH_PGR. Therefore the in-core pr emulation is active by default, but there are some attributes for configuration missing. Add them. Link: https://lore.kernel.org/r/20200427150823.15350-3-bstroesser@ts.fujitsu.comReviewed-by:
-
Bodo Stroesser authored
In commit b49d6f78 ("scsi: target: add emulate_pr backstore attr to toggle PR support") the new attribute emulate_pr was added. passthrough_parse_cdb() uses the attribute's value to distinguish whether reservation commands should be rejected or not. But the new attribute was not added to passthrough_attrib_attrs, so in pscsi and tcmu - the users of passthrough_parse_cdb() - the attribute is not available to change parser's behavior. Link: https://lore.kernel.org/r/20200427150823.15350-2-bstroesser@ts.fujitsu.comReviewed-by:
-
Sreekanth Reddy authored
By default DIF Type 1, DIF Type 2 & DIF Type 3 will be enabled. Also, users can enable either DIF Type 1 or DIF Type 2 or DIF Type 3 or in any combination using the prot_mask module parameter. However, when the user provides a prot_mask module parameter value of zero, then the driver is not disabling the DIF. Instead it enables all three types. Modify the driver to disable the DIF support if the user provides a prot_mask module parameter value of zero. Link: https://lore.kernel.org/r/1588065902-2726-1-git-send-email-sreekanth.reddy@broadcom.comSigned-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Suganath Prabu authored
Updated maintainers list for MPT DRIVERS Link: https://lore.kernel.org/r/1588056428-29369-1-git-send-email-suganath-prabu.subramani@broadcom.comSigned-off-by:
Suganath Prabu <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Suganath Prabu authored
Information needed to debug driver problems and firmware faults is stored in the IOC’s MPT3SAS_ADAPTER data structure. Parameters such as IOCFacts, IOC flags (related to sge, MSI-X, error recovery etc.), performance mode type, TMs, internal commands reply status, etc. are present. For debugging purposes, it is therefore helpful to be able to capture this information so that the fault can be analyzed. Export the MPT3SAS_ADAPTER data structure in debugfs. The data is available in: /sys/kernel/debug/mpt3sas/scsi_hostX/ioc_dump Link: https://lore.kernel.org/r/1588056322-29227-1-git-send-email-suganath-prabu.subramani@broadcom.comSigned-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/mpt3sas/mpt3sas_base.c:7202:1-19: WARNING: Assignment of 0/1 to bool variable Link: https://lore.kernel.org/r/20200430121738.15151-1-yanaijie@huawei.comSigned-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/vmw_pvscsi.c:911:2-18: WARNING: Assignment of 0/1 to bool variable Link: https://lore.kernel.org/r/20200430121729.15064-1-yanaijie@huawei.comSigned-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/fnic/fnic_scsi.c:2627:5-36: WARNING: Comparison of 0/1 to bool variable Link: https://lore.kernel.org/r/20200430121718.14970-1-yanaijie@huawei.comSigned-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/qedi/qedi_main.c:1309:5-25: WARNING: Comparison of 0/1 to bool variable drivers/scsi/qedi/qedi_main.c:1315:5-25: WARNING: Comparison of 0/1 to bool variable Link: https://lore.kernel.org/r/20200430121706.14879-1-yanaijie@huawei.comAcked-by:
Manish Rangankar <mrangankar@marvell.com> Signed-off-by:
-
Zou Wei authored
Fix the following sparse warnings: drivers/scsi/aacraid/linit.c:867:6: warning: symbol 'aac_tmf_callback' was not declared. Should it be static? drivers/scsi/aacraid/linit.c:1081:5: warning: symbol 'aac_eh_host_reset' was not declared. Should it be static? drivers/scsi/aacraid/commsup.c:2354:5: warning: symbol 'aac_send_safw_hostttime' was not declared. Should it be static? drivers/scsi/aacraid/commsup.c:2383:5: warning: symbol 'aac_send_hosttime' was not declared. Should it be static? Link: https://lore.kernel.org/r/1588240932-69020-1-git-send-email-zou_wei@huawei.comReported-by:
-
Jason Yan authored
No other functions use the return value of qlafx00_process_aen() and the return value is always 0 now. Make it return void. This fixes the following coccicheck warning: drivers/scsi/qla2xxx/qla_mr.c:1716:5-9: Unneeded variable: "rval". Return "0" on line 1768 Link: https://lore.kernel.org/r/20200506061757.19536-1-yanaijie@huawei.comReviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
