- 05 Jul, 2024 19 commits
-
-
Martin K. Petersen authored
Sumit Saxena <sumit.saxena@broadcom.com> says: This patch series contains the changes done in the driver to support PCI error recovery. It is rework of older patch series from Ranjan Kumar, see [1]. [1] https://lore.kernel.org/all/20231214205900.270488-1-ranjan.kumar@broadcom.com/ Link: https://lore.kernel.org/r/20240627101735.18286-1-sumit.saxena@broadcom.comSigned-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Sumit Saxena authored
Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Link: https://lore.kernel.org/r/20240627101735.18286-4-sumit.saxena@broadcom.comSigned-off-by:
-
Sumit Saxena authored
Prevent interaction with the hardware while the error recovery in progress. Co-developed-by:
Sathya Prakash <sathya.prakash@broadcom.com> Signed-off-by:
Ranjan Kumar <ranjan.kumar@broadcom.com> Signed-off-by:
-
Sumit Saxena authored
PCI Error recovery support is required to recover the controller upon detection of PCI errors. Add support for the PCI error recovery callback handlers in mpi3mr driver. Co-developed-by:
-
Martin K. Petersen authored
Justin Tee <justintee8345@gmail.com> says: Update lpfc to revision 14.4.0.3 This patch set contains bug fixes related to discovery, submission of mailbox commands, and proper endianness conversions. The patches were cut against Martin's 6.11/scsi-queue tree. Link: https://lore.kernel.org/r/20240628172011.25921-1-justintee8345@gmail.comSigned-off-by:
-
Justin Tee authored
Update lpfc version to 14.4.0.3. Signed-off-by:
Justin Tee <justin.tee@broadcom.com> Link: https://lore.kernel.org/r/20240628172011.25921-9-justintee8345@gmail.comSigned-off-by:
-
Justin Tee authored
On big endian architectures, it is possible to run into a memory out of bounds pointer dereference when FCP targets are zoned. In lpfc_prep_embed_io, the memcpy(ptr, fcp_cmnd, sgl->sge_len) is referencing a little endian formatted sgl->sge_len value. So, the memcpy can cause big endian systems to crash. Redefine the *sgl ptr as a struct sli4_sge_le to make it clear that we are referring to a little endian formatted data structure. And, update the routine with proper le32_to_cpu macro usages. Fixes: af20bb73 ("scsi: lpfc: Add support for 32 byte CDBs") Signed-off-by:
-
Justin Tee authored
When setting trunk modes through sysfs, the SLI_CONFIG mailbox command's command payload length is incorrectly hardcoded to 12 bytes. SLI_CONFIG's payload length field should be specified large enough to encompass both the submailbox command header and the submailbox request itself. Thus, replace the hardcoded 12 bytes with a clearer calculation by way of sizeof(struct lpfc_mbx_set_trunk_mode) - sizeof(struct lpfc_sli4_cfg_mhdr). Signed-off-by:
-
Justin Tee authored
The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the routine unconditionally frees submitted mailbox commands regardless of return status. The issue is that for MBX_TIMEOUT cases, when firmware returns SFP information at a later time, that same mailbox memory region references previously freed memory in its cmpl routine. Fix by adding checks for the MBX_TIMEOUT return code. During mailbox resource cleanup, check the mbox flag to make sure that the wait did not timeout. If the MBOX_WAKE flag is not set, then do not free the resources because it will be freed when firmware completes the mailbox at a later time in its cmpl routine. Also, increase the timeout from 30 to 60 seconds to accommodate boot scripts requiring longer timeouts. Signed-off-by:
-
Justin Tee authored
In rare cases when a fabric node is recovered after a link bounce and before dev_loss_tmo callbk is reached, the driver may leave the fabric node in an inconsistent state with the NLP_IN_DEV_LOSS flag perpetually set. In lpfc_dev_loss_tmo_callbk, a check is added for a recovered fabric node. If the node is recovered, then don't queue the lpfc_dev_loss_tmo_handler work. In lpfc_dev_loss_tmo_handler, the path taken for the recovered fabric nodes is updated to clear the NLP_IN_DEV_LOSS flag. Signed-off-by:
-
Justin Tee authored
If previously in REG_LOGIN_ISSUE state, then remove the requirement that PLOGI must have been received from the remote port before issuing a PRLI. After GID_FT completes, it does not matter whether the driver itself sent a PLOGI or received one. The fact that we're in REG_LOGIN_ISSUE state simply means that the next state should be issuing the PRLI to continue discovery of the remote port. Signed-off-by:
-
Justin Tee authored
Certain vendor specific targets initially register with the fabric as an initiator function first and then re-register as a target function afterwards. The timing of the target function re-registration can cause a race condition such that the driver is stuck assuming the remote port as an initiator function and never discovers the target's hosted LUNs. Expand the nlp_state qualifier to also include NLP_STE_PRLI_ISSUE because the state means that PRLI was issued but we have not quite reached MAPPED_NODE state yet. If we received an RSCN in the PRLI_ISSUE state, then we should restart discovery again by going into DEVICE_RECOVERY. Fixes: dded1dc3 ("scsi: lpfc: Modify when a node should be put in device recovery mode during RSCN") Cc: <stable@vger.kernel.org> # v6.6+ Signed-off-by:
-
Justin Tee authored
During SLI port errata events, there should be no expectation that submitted outstanding WQEs will return back CQEs. In these situations, the driver should not rely on receiving CQEs from the SLI port to signal WQE resource clean up. Put an sli_flag LPFC_SLI_ACTIVE check in lpfc_els_flush_cmd() when walking the txcmplq. The sli_flag check helps determine whether to issue an abort or driver based cancel on outstanding WQEs. If !LPFC_SLI_ACTIVE, then there's no point to issue anything to the SLI port. Instead, let the driver based cancel logic clean up the submitted WQE resources. Also, enhance some abort log messages that help with future debugging. Signed-off-by:
-
Terrence Adams authored
Reading the main config table occurs as a part of initialization in pm80xx_chip_init(). Because of this it makes more sense to have it be a part of the INIT logging. Signed-off-by:
Terrence Adams <tadamsjr@google.com> Link: https://lore.kernel.org/r/20240627155924.2361370-3-tadamsjr@google.comAcked-by:
Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
-
Igor Pylypiv authored
pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash. Signed-off-by:
Igor Pylypiv <ipylypiv@google.com> Signed-off-by:
-
Kyoungrul Kim authored
If host tries to remove ufshcd driver from a UFS device it would cause a kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host has been defered after MCQ configuration introduced by commit 0cab4023 ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported"). To guarantee that SCSI host is removed only if it has been added, set the scsi_host_added flag to true after adding a SCSI host and check whether it is set or not before removing it. Signed-off-by:
Kyoungrul Kim <k831.kim@samsung.com> Signed-off-by:
Minwoo Im <minwoo.im@samsung.com> Link: https://lore.kernel.org/r/20240627085104epcms2p5897a3870ea5c6416aa44f94df6c543d7@epcms2p5Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Ram Prakash Gupta authored
Enable suspending clk scaling on no request for Qualcomm SoC. Signed-off-by:
Ram Prakash Gupta <quic_rampraka@quicinc.com> Link: https://lore.kernel.org/r/20240627083756.25340-3-quic_rampraka@quicinc.comReviewed-by:
-
Ram Prakash Gupta authored
Currently UFS clk scaling is getting suspended only when the clks are scaled down. When high load is generated, a huge amount of latency is added due to scaling up the clk and completing the request post that. Suspending the scaling in its existing state when high load is generated improves the random performance KPI by 28%. So suspending the scaling when there are no requests. And the clk would be put in low scaled state when the actual request load is low. Make this change optional by having the check enabled using vops since for some devices suspending without bringing the clk in low scaled state might have impact on power consumption of the SoC. Signed-off-by:
-
Tomas Henzl authored
The test for a possible shift overflow is not correct. Fix it by replacing the '>' with a '>='. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Link: https://lore.kernel.org/r/20240627074827.13672-1-thenzl@redhat.comSuggested-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
- 27 Jun, 2024 8 commits
-
-
Martin K. Petersen authored
Ranjan Kumar <ranjan.kumar@broadcom.com> says: The controllers managed by mpi3mr driver requires system memory to save hardware and firmware diagnostic information, this patch set enhances the drivers to provide host memory to the controller for diagnostic information. This patch set also provides driver changes to push kernel messages into the diagnostic buffers reserved for the driver, so that the information will be available as part of debug data fetched from the controller. In addition, support for configuring automatic diagnostic information is added in the driver. Link: https://lore.kernel.org/r/20240626102646.14298-1-ranjan.kumar@broadcom.comSigned-off-by:
-
Ranjan Kumar authored
Update driver version to 8.9.1.0.50 Signed-off-by:
-
Ranjan Kumar authored
Add interface for applications to manage the host diagnostic buffers and update the automatic diag buffer capture triggers. Co-developed-by:
-
Ranjan Kumar authored
Add functions to process automatic diag triggers. If a condition defined in the triggers is met, the driver will call appropriate controller functions to save the diagnostic information. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202405151955.BiAWI1SY-lkp@intel.com/Co-developed-by:
-
Ranjan Kumar authored
To be able to debug controller problems it is beneficial to allocate and configure system/host memory buffers which can be used to capture hardware and firmware diagnostic information. Add functions required to allocate and post firmware and hardware diagnostic buffers to the controller and to set up automatic diagnostic capture triggers. Captures will be triggered under the following circumstances: 1. Firmware is in FAULT state. 2. Admin commands time out. 3. Controller reset caused due to I/O timeout Reported-by:
-
Adrian Hunter authored
Add PCI ID to support Intel Panther Lake, same as MTL. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20240618073158.38504-1-adrian.hunter@intel.comReviewed-by:
-
Jeff Johnson authored
With ARCH=arm64, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/ufs/host/ufs-qcom.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240625-md-drivers-ufs-host-v2-1-59a56974b05a@quicinc.comSigned-off-by:
-
Huai-Yuan Liu authored
In function lpfc_xcvr_data_show, the memory allocation with kmalloc might fail, thereby making rdp_context a null pointer. In the following context and functions that use this pointer, there are dereferencing operations, leading to null pointer dereference. To fix this issue, a null pointer check should be added. If it is null, use scnprintf to notify the user and return len. Fixes: 479b0917 ("scsi: lpfc: Create a sysfs entry called lpfc_xcvr_data for transceiver info") Signed-off-by:
Huai-Yuan Liu <qq810974084@gmail.com> Link: https://lore.kernel.org/r/20240621082545.449170-1-qq810974084@gmail.comReviewed-by:
-
- 13 Jun, 2024 1 commit
-
-
Bart Van Assche authored
The comment that scsi_static_device_list would go away was added more than 18 years ago. Today, that list is still there and a large number of additional entries have been added. This shows that this comment is incorrect. Hence fix that comment. Cc: Christoph Hellwig <hch@infradead.org> Cc: Avri Altman <Avri.Altman@wdc.com> Signed-off-by:
-
- 12 Jun, 2024 1 commit
-
-
Jeff Johnson authored
On x86, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/scsi/scsi_common.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/scsi/advansys.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/scsi/BusLogic.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/scsi/aha1740.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/scsi/isci/isci.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/scsi/elx/efct.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/scsi/atp870u.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/scsi/ppa.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/scsi/imm.o Add all missing invocations of the MODULE_DESCRIPTION() macro. This updates all files which have a MODULE_LICENSE() but which do not have a MODULE_DESCRIPTION(), even ones which did not produce the x86 allmodconfig warnings. Acked-by:
Finn Thain <fthain@linux-m68k.org> Signed-off-by:
-
- 05 Jun, 2024 8 commits
-
-
Martin K. Petersen authored
Bart Van Assche <bvanassche@acm.org> says: Hi Martin, There are several 32-bit ARM SCSI drivers that trigger compiler warnings about missing function declarations. This patch series fixes these compiler warnings by declaring local functions static. Please consider this patch series for the next merge window. Thanks, Bart. Link: https://lore.kernel.org/r/20240603172311.1587589-1-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
Signed-off-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
-
Bart Van Assche authored
Signed-off-by:
-
Bart Van Assche authored
Signed-off-by:
-
Bart Van Assche authored
Signed-off-by:
-
Martin K. Petersen authored
Minwoo Im <minwoo.im@samsung.com> says: This patchset introduces add support for MCQ introduced in UFSHCI 4.0. The first patch adds a simple helper to get the address of MCQ queue config registers. The second one enables MCQ feature by adding mandatory vops callback functions required at MCQ initialization phase. The last one is to prevent a case where number of MCQ is given 1 since driver allocates poll_queues first rather than I/O queues to handle device commands. Instead of causing exception handlers due to no I/O queue, failfast during the initialization time. Link: https://lore.kernel.org/r/20240531212244.1593535-1-minwoo.im@samsung.comSigned-off-by:
-
Minwoo Im authored
If hba_maxq equals poll_queues, which means there are no I/O queues (HCTX_TYPE_DEFAULT, HCTX_TYPE_READ), the very first hw queue will be allocated as HCTX_TYPE_POLL and it will be used as the dev_cmd_queue. In this case, device commands such as QUERY cannot be properly handled. This patch prevents the initialization of MCQ when the number of I/O queues is not set and only the number of POLL queues is set. Signed-off-by:
-
Minwoo Im authored
Recently, ufs-mcq feature has been introduced to QEMU hw/ufs device [1]. This patch adds MCQ support for upstream QEMU UFS PCI controller. This patch provides mandatory vops callbacks to make UFS controller work properly on MCQ mode. Operation and Runtime Config register stride is fixed to 48bytes which is implemented by qemu. [1] https://lore.kernel.org/qemu-devel/cover.1716876237.git.jeuk20.kim@samsung.com/Signed-off-by:
-
- 31 May, 2024 3 commits
-
-
Minwoo Im authored
Inline functions are preferred over macros. Convert the MCQ_CFG_n macro to an inline function. Signed-off-by:
-
Minwoo Im authored
The MCQ_OPR_OFFSET_n macro takes 'hba' in the caller context without receiving 'hba' instance as an argument. To prevent potential bugs in future use cases, add an argument 'hba'. Fixes: 2468da61 ("scsi: ufs: core: mcq: Configure operation and runtime interface") Cc: Asutosh Das <quic_asutoshd@quicinc.com> Signed-off-by:
-
Martin K. Petersen authored
Avri Altman <avri.altman@wdc.com> says: The rtt-upiu packets precede any data-out upiu packets, thus synchronizing the data input to the device: this mostly applies to write operations, but there are other operations that requires rtt as well. There are several rules binding this rtt - data-out dialog, specifically There can be at most outstanding bMaxNumOfRTT such packets. This might have an effect on write performance (sequential write in particular), as each data-out upiu must wait for its rtt sibling. UFSHCI expects bMaxNumOfRTT to be min(bDeviceRTTCap, NORTT). However, as of today, there does not appear to be no-one who sets it: not the host controller nor the driver. It wasn't an issue up to now: bMaxNumOfRTT is set to 2 after manufacturing, and wasn't limiting the write performance. UFS4.0, and specifically gear 5 changes this, and requires the device to be more attentive. This doesn't come free - the device has to allocate more resources to that end, but the sequential write performance improvement is significant. Early measurements shows 25% gain when moving from rtt 2 to 9. Therefore, set bMaxNumOfRTT to be min(bDeviceRTTCap, NORTT) as UFSHCI expects. Link: https://lore.kernel.org/r/20240530142510.734-1-avri.altman@wdc.comSigned-off-by:
-
