- 11 May, 2022 4 commits
-
-
Manivannan Sadhasivam authored
In ufs_qcom_dev_ref_clk_ctrl(), it was noted that the ref_clk needs to be stable for at least 1us. Even though there is wmb() to make sure the write gets "completed", there is no guarantee that the write actually reached the UFS device. There is a good chance that the write could be stored in a Write Buffer (WB). In that case, even though the CPU waits for 1us, the ref_clk might not be stable for that period. So lets do a readl() to make sure that the previous write has reached the UFS device before udelay(). Also, the wmb() after writel_relaxed() is not really needed. Both writel() and readl() are ordered on all architectures and the CPU won't speculate instructions after readl() due to the in-built control dependency with read value on weakly ordered architectures. So it can be safely removed. Link: https://lore.kernel.org/r/20220504084212.11605-4-manivannan.sadhasivam@linaro.org Fixes: f06fcc71 ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations") Cc: stable@vger.kernel.org Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Manivannan Sadhasivam authored
There is no need to call devm_phy_get() if ACPI is used, so skip it. The host->generic_phy pointer should already be NULL due to the kzalloc(), so no need to set it NULL again. While at it, also remove the comment that has no relationship with devm_phy_get(). Link: https://lore.kernel.org/r/20220504084212.11605-3-manivannan.sadhasivam@linaro.orgReviewed-by:
Andrew Halaney <ahalaney@redhat.com> Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom UFS platforms, the reset control line seems to be optional (for SoCs like MSM8996 and probably for others too). The current logic tries to mimic the devm_reset_control_get_optional() API but it also continues the probe if there is an error with the declared reset line in DT/ACPI. In an ideal case, if the reset line is not declared in DT/ACPI, the probe should continue. But if there is problem in acquiring the declared reset line (like EPROBE_DEFER) it should fail and return the appropriate error code. Link: https://lore.kernel.org/r/20220504084212.11605-2-manivannan.sadhasivam@linaro.orgReviewed-by:
-
Xiang Chen authored
If we fail to notify the phy up event then undo the RPM resume, as the phy up notify event handling pairs with that RPM resume. Link: https://lore.kernel.org/r/1651839939-101188-1-git-send-email-john.garry@huawei.comReported-by:
Yihang Li <liyihang6@hisilicon.com> Tested-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
- 02 May, 2022 21 commits
-
-
Sumit Saxena authored
Link: https://lore.kernel.org/r/20220429211641.642010-9-sumit.saxena@broadcom.comSigned-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Sumit Saxena authored
Add support for management applications to send an MPI3 Encapsulated NVMe passthru command to the NVMe devices attached to an Avenger controller. Since the NVMe drives are exposed as SCSI devices by the controller, the standard NVMe applications cannot be used to interact with the drives and the command sets supported are also limited by the controller firmware. Special handling is required for MPI3 Encapsulated NVMe passthru commands for PRP/SGL setup in the commands. Link: https://lore.kernel.org/r/20220429211641.642010-8-sumit.saxena@broadcom.comReviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
-
Sumit Saxena authored
Link: https://lore.kernel.org/r/20220429211641.642010-7-sumit.saxena@broadcom.comReviewed-by:
-
Sumit Saxena authored
Implement driver support for management applications to enable persistent event log (PEL) notifications. Upon receipt of events, the driver will increment a sysfs variable named event_counter. The management application will poll for event_counter value changes and signal the application about events. Link: https://lore.kernel.org/r/20220429211641.642010-6-sumit.saxena@broadcom.comReviewed-by:
-
Sumit Saxena authored
There are certain management commands which require firmware intervention. These commands are termed MPT commands. Add support for them. Link: https://lore.kernel.org/r/20220429211641.642010-5-sumit.saxena@broadcom.comReviewed-by:
-
Sumit Saxena authored
This patch moves the data structures/definitions which are used by userspace applications from MPI headers to uapi/scsi/scsi_bsg_mpi3mr.h Link: https://lore.kernel.org/r/20220429211641.642010-4-sumit.saxena@broadcom.com Reported by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by:
-
Sumit Saxena authored
There are certain bsg commands which need to be completed by the driver without involving firmware. These requests are termed driver commands. Add support for these. Link: https://lore.kernel.org/r/20220429211641.642010-3-sumit.saxena@broadcom.com Reported by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Sumit Saxena authored
Create bsg device per controller for controller management purposes. bsg device nodes will be named /dev/bsg/mpi3mrctl0, /dev/bsg/mpi3mrctl1, etc. Link: https://lore.kernel.org/r/20220429211641.642010-2-sumit.saxena@broadcom.comReported-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
-
Enze Li authored
The function get_capabilities() has the possibility of failing to allocate the transfer buffer but it does not currently handle this. This may lead to exceptions when accessing the buffer. Add error handling when memory allocation fails. Link: https://lore.kernel.org/r/20220427025647.298358-1-lienze@kylinos.cnSigned-off-by:
Enze Li <lienze@kylinos.cn> Signed-off-by:
-
Xiaoguang Wang authored
When tcmu_vma_fault() gets a page successfully, before the current context completes page fault procedure, find_free_blocks() may run and call unmap_mapping_range() to unmap the page. Assume that when find_free_blocks() initially completes and the previous page fault procedure starts to run again and completes, then one truncated page has been mapped to userspace. But note that tcmu_vma_fault() has gotten a refcount for the page so any other subsystem won't be able to use the page unless the userspace address is unmapped later. If another command subsequently runs and needs to extend dbi_thresh it may reuse the corresponding slot for the previous page in data_bitmap. Then though we'll allocate new page for this slot in data_area, no page fault will happen because we have a valid map and the real request's data will be lost. Filesystem implementations will also run into this issue but they usually lock the page when vm_operations_struct->fault gets a page and unlock the page after finish_fault() completes. For truncate filesystems lock pages in truncate_inode_pages() to protect against racing wrt. page faults. To fix this possible data corruption scenario we can apply a method similar to the filesystems. For pages that are to be freed, tcmu_blocks_release() locks and unlocks. Make tcmu_vma_fault() also lock found page under cmdr_lock. At the same time, since tcmu_vma_fault() gets an extra page refcount, tcmu_blocks_release() won't free pages if pages are in page fault procedure, which means it is safe to call tcmu_blocks_release() before unmap_mapping_range(). With these changes tcmu_blocks_release() will wait for all page faults to be completed before calling unmap_mapping_range(). And later, if unmap_mapping_range() is called, it will ensure stale mappings are removed. Link: https://lore.kernel.org/r/20220421023735.9018-1-xiaoguang.wang@linux.alibaba.comReviewed-by:
Bodo Stroesser <bostroesser@gmail.com> Signed-off-by:
Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com> Signed-off-by:
-
James Smart authored
Prior patch added a call to lpfc_sli_prep_wqe() prior to lpfc_sli_issue_iocb(). This call should not have been added as prep_wqe is called within the issue_iocb routine. So it's called twice now. Remove the redundant prep call. Link: https://lore.kernel.org/r/20220427222223.57920-1-jsmart2021@gmail.com Fixes: 31a59f75 ("scsi: lpfc: SLI path split: Refactor Abort paths") Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
James Smart authored
Code inspection has found an additional reference is taken in lpfc_bsg_rport_els(). Results in the ndlp not being freed thus is leaked. Fix by removing the redundant refcount taken before WQE submission. Link: https://lore.kernel.org/r/20220427222158.57867-1-jsmart2021@gmail.comCo-developed-by:
Nigel Kirkland <nigel.kirkland@broadcom.com> Signed-off-by:
-
Martin K. Petersen authored
During device discovery we ended up calling revalidate twice and thus requested the same parameters multiple times. This was originally necessary due to the request_queue and gendisk needing to be instantiated to configure the block integrity profile. Since this dependency no longer exists, reorganize the integrity probing code so it can be run once at the end of discovery and drop the superfluous revalidate call. Postponing the registration step involves splitting sd_read_protection() into two functions, one to read the device protection type and one to configure the mode of operation. As part of this cleanup, make the printing code a bit less verbose. Link: https://lore.kernel.org/r/20220302053559.32147-14-martin.petersen@oracle.comReviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
-
Martin K. Petersen authored
Commit a83da8a4 ("scsi: sd: Optimal I/O size should be a multiple of physical block size") validated the reported optimal I/O size against the physical block size to overcome problems with devices reporting nonsensical transfer sizes. However, some devices claim conformity to older SCSI versions that predate the physical block size being reported. Other devices do not report a physical block size at all. We need to be able to validate the optimal I/O size on those devices as well. Many devices report an OPTIMAL TRANSFER LENGTH GRANULARITY in the same VPD page as the OPTIMAL TRANSFER LENGTH. Use this value to validate the optimal I/O size. Also check that the reported granularity is a multiple of the physical block size, if supported. Link: https://lore.kernel.org/r/33fb522e-4f61-1b76-914f-c9e6a3553c9b@gmail.com Link: https://lore.kernel.org/r/20220302053559.32147-9-martin.petersen@oracle.comReported-by:
Bernhard Sulzer <micraft.b@gmail.com> Reviewed-by:
-
Martin K. Petersen authored
Use the VPD pages already provided by the SCSI midlayer. No need to request them individually in the SCSI disk driver. Link: https://lore.kernel.org/r/20220302053559.32147-8-martin.petersen@oracle.comReviewed-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
-
Martin K. Petersen authored
Since the ATA Information VPD is now cached at device discovery time it is no longer necessary to request this page when we configure WRITE SAME. Instead use the cached information to determine if this disk sits behind a SCSI-ATA translation layer. Link: https://lore.kernel.org/r/20220302053559.32147-7-martin.petersen@oracle.comReviewed-by:
-
Martin K. Petersen authored
Low-level device drivers have had the ability to limit the size of an INQUIRY for many years. This made sense for a wide variety of legacy devices. However, we are unnecessarily truncating the INQUIRY response for many modern devices. This prevents us from consulting fields beyond the first 36 bytes. If a device reports that it supports a larger INQUIRY response, and the device also reports that it implements SPC-4 or newer, allow the larger INQUIRY to proceed. Link: https://lore.kernel.org/r/20220302053559.32147-4-martin.petersen@oracle.comReviewed-by:
-
Martin K. Petersen authored
The SCSI disk driver consults VPD pages b0 (Block Limits), b1 (Block Device Characteristics), and b2 (Logical Block Provisioning). Instead of having sd.c request these pages every revalidate cycle, cache them along with the other commonly used VPDs. Link: https://lore.kernel.org/r/20220302053559.32147-6-martin.petersen@oracle.comReviewed-by:
-
Martin K. Petersen authored
Some devices hang when a buffer size larger than expected is passed in the ALLOCATION LENGTH field. For REPORT SUPPORTED OPERATION CODES we currently only request a single command descriptor at a time and therefore the actual size of the command is known ahead of time. Limit the ALLOCATION LENGTH to the header size plus the command length of the opcode we are asking about. Link: https://lore.kernel.org/r/20220302053559.32147-5-martin.petersen@oracle.comReviewed-by:
-
Martin K. Petersen authored
We currently default to 255 bytes when fetching VPD pages during discovery. However, we have had a few devices that are known to wedge if the requested buffer exceeds a certain size. See commit af73623f ("[SCSI] sd: Reduce buffer size for vpd request") which works around one example of this problem in the SCSI disk driver. With commit d188b067 ("scsi: core: Add sysfs attributes for VPD pages 0h and 89h") we now risk triggering the same issue in the generic midlayer code. The problem with the ATA VPD page in particular is that the SCSI portion of the page is trailed by 512 bytes of verbatim ATA Identify Device information. However, not all controllers actually provide the additional 512 bytes and will lock up if one asks for more than the 64 bytes containing the SCSI protocol fields. Instead of picking a new, somewhat arbitrary, number of bytes for the VPD buffer size, start fetching the 4-byte header for each page. The header contains the size of the page as far as the device is concerned. We can use the reported size to specify the correct allocation length when subsequently fetching the full page. The header validation is done by a new helper function scsi_get_vpd_size() and both scsi_get_vpd_page() and scsi_get_vpd_buf() now rely on this to query the page size. In addition, scsi_get_vpd_page() is simplified to mirror the logic in scsi_get_vpd_page(). This involves removing the Supported VPD Pages lookup prior to attempting to query a page. There does not appear any evidence, even in the oldest SCSI specs, that this step is required. We already rely on scsi_get_vpd_page() throughout the stack and this function never consulted the Supported VPD Pages. Since this has not caused any problems it should be safe to remove the precondition from scsi_get_vpd_page(). Instrumented runs also revealed that the Supported VPD Pages lookup had little effect since the device page index often was larger than the supplied buffer size. As a result, inquiries frequently bypassed the index check and went through the "If we ran off the end of the buffer, give us the benefit of the doubt" code path which assumed the page was present despite not being listed. The revised code takes both the page size reported by the device as well as the size of the buffer provided by the scsi_get_vpd_page() caller into account. Link: https://lore.kernel.org/r/20220302053559.32147-3-martin.petersen@oracle.com Fixes: d188b067 ("scsi: core: Add sysfs attributes for VPD pages 0h and 89h") Reported-by:
Maciej W. Rozycki <macro@orcam.me.uk> Tested-by:
-
Martin K. Petersen authored
We now cache VPD page 0x89 (ATA Information) so there is no need to request it from the hardware. Make mpt3sas use the cached page. Link: https://lore.kernel.org/r/20220302053559.32147-2-martin.petersen@oracle.com Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Reviewed-by:
-
- 27 Apr, 2022 3 commits
-
-
James Smart authored
If no handler is found in lpfc_complete_unsol_iocb() to match the rctl of a received frame, the frame is dropped and resources are leaked. Fix by returning resources when discarding an unhandled frame type. Update lpfc_fc_frame_check() handling of NOP basic link service. Link: https://lore.kernel.org/r/20220426181419.9154-1-jsmart2021@gmail.comCo-developed-by:
Justin Tee <justin.tee@broadcom.com> Signed-off-by:
-
James Smart authored
Smatch had the following warning: drivers/scsi/lpfc/lpfc_sli.c:22305 lpfc_sli_prep_wqe() error: we previously assumed 'ndlp' could be null (see line 22298) Remove the unnecessary null check. Link: https://lore.kernel.org/r/20220426181315.8990-1-jsmart2021@gmail.com Fixes: d51cf5bd ("scsi: lpfc: Fix field overload in lpfc_iocbq data structure") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Minghao Chi authored
Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync() and pm_runtime_put_noidle(). This change is just to simplify the code, no actual functional changes. Link: https://lore.kernel.org/r/20220420090353.2588804-1-chi.minghao@zte.com.cnReported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
-
- 26 Apr, 2022 12 commits
-
-
Lv Ruyi authored
If major equals 0, register_chrdev() returns an error code when it fails. This function dynamically allocates a major and returns its number on success, so we should use "< 0" to check it instead of "!". Link: https://lore.kernel.org/r/20220418105755.2558828-1-lv.ruyi@zte.com.cnReported-by:
Lv Ruyi <lv.ruyi@zte.com.cn> Signed-off-by:
-
Guo Zhengkui authored
Fix the following coccicheck warning: drivers/scsi/qla2xxx/qla_edif.c:660:11-15: Unneeded variable: "rval". Return "0" on line 761. Link: https://lore.kernel.org/r/20220426074334.9281-1-guozhengkui@vivo.comSigned-off-by:
Guo Zhengkui <guozhengkui@vivo.com> Signed-off-by:
-
Xiaomeng Tong authored
The bug is here: p->target_id, p->target_lun); The list iterator 'p' will point to a bogus position containing HEAD if the list is empty or no element is found. This case must be checked before any use of the iterator, otherwise it will lead to an invalid memory access. To fix this bug, add a check. Use a new variable 'iter' as the list iterator, and use the original variable 'p' as a dedicated pointer to point to the found element. Link: https://lore.kernel.org/r/20220414040231.2662-1-xiam0nd.tong@gmail.com Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by:
Xiaomeng Tong <xiam0nd.tong@gmail.com> Signed-off-by:
-
Xiaomeng Tong authored
The list iterator 'fcport' is always non-NULL so it doesn't need to be checked. Thus just remove the unnecessary NULL check. Also remove the unnecessary initializer because the list iterator is always initialized. And adjust the position of blank lines. Link: https://lore.kernel.org/r/20220405004055.24312-1-xiam0nd.tong@gmail.comSigned-off-by:
-
Wan Jiabing authored
Fix following checkincludes warning: drivers/scsi/ufs/ufshcd.c: linux/nls.h is included more than once. The include is in line 14. Remove the duplicate. Link: https://lore.kernel.org/r/20220426104509.621394-1-wanjiabing@vivo.comReviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
-
Kiwoong Kim authored
Some devices may return invalid or zeroed data during an UIC error condition. In addition, reading these SFRs will clear them. This means the subsequent error handling will not be able to see them and therefore no error handling will be scheduled. Skip reading these SFRs in ufshcd_dump_regs(). Link: https://lore.kernel.org/r/1648689845-33521-1-git-send-email-kwmad.kim@samsung.com Fixes: d6724756 ("scsi: ufs: Use explicit access size in ufshcd_dump_regs") Signed-off-by:
Kiwoong Kim <kwmad.kim@samsung.com> Signed-off-by:
-
John Garry authored
For SCSI hosts which enable host_tagset the NUMA node returned from blk_mq_hw_queue_to_node() is NUMA_NO_NODE always. Then, since in scsi_mq_setup_tags() the default we choose for the tag_set NUMA node is NUMA_NO_NODE, we always evaluate the NUMA node as NUMA_NO_NODE in functions like blk_mq_alloc_rq_map(). The reason we get NUMA_NO_NODE from blk_mq_hw_queue_to_node() is that the hctx_idx passed is BLK_MQ_NO_HCTX_IDX - so we can't match against a (HW) queue mapping index. Improve this by defaulting the tag_set NUMA node to the same NUMA node of the SCSI host DMA dev. Link: https://lore.kernel.org/r/1648640315-21419-1-git-send-email-john.garry@huawei.comSigned-off-by:
-
Changcheng Deng authored
Remove unneeded variable 'rc' used to store return value. Link: https://lore.kernel.org/r/20220419065750.2573861-1-deng.changcheng@zte.com.cnReported-by:
Changcheng Deng <deng.changcheng@zte.com.cn> Signed-off-by:
-
ran jianping authored
All work currently pending will be done first by calling destroy_workqueue(). There is no need to flush it explicitly. Link: https://lore.kernel.org/r/20220424065406.3228528-1-ran.jianping@zte.com.cnReported-by:
ran jianping <ran.jianping@zte.com.cn> Signed-off-by:
-
ran jianping authored
All work currently pending will be done first by calling destroy_workqueue(). There is no need to flush it explicitly. Link: https://lore.kernel.org/r/20220424062413.3220315-1-ran.jianping@zte.com.cnReported-by:
-
ran jianping authored
All work currently pending will be done first by calling destroy_workqueue(). There is no need to flush it explicitly. Link: https://lore.kernel.org/r/20220424061845.3218774-1-ran.jianping@zte.com.cnReported-by:
-
Haowen Bai authored
Buffer 'msg' is memset() but never actually used. Drop it. Link: https://lore.kernel.org/r/1650536693-13089-1-git-send-email-baihaowen@meizu.comSigned-off-by:
Haowen Bai <baihaowen@meizu.com> Signed-off-by:
-
