- 14 Dec, 2023 40 commits
-
-
Martin K. Petersen authored
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> says: Hello, This series has code some cleanups to the Qcom UFS driver. No functional change. In this version, I've removed code supporting legacy controllers ver < 2.0, as the respective platforms were never supported in upstream. Tested on: RB5 development board based on Qcom SM8250 SoC. Link: https://lore.kernel.org/r/20231208065902.11006-1-manivannan.sadhasivam@linaro.orgSigned-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Manivannan Sadhasivam authored
Remove unused definitions. Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20231208065902.11006-18-manivannan.sadhasivam@linaro.orgReviewed-by:
Andrew Halaney <ahalaney@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8775p-ride Signed-off-by:
-
Manivannan Sadhasivam authored
Instead of using both ufshcd_readl() and ufshcd_writel() to read/modify/ write a register, let's make use of the existing helper. Signed-off-by:
-
Manivannan Sadhasivam authored
The legacy platforms making use of host controllers older than version 2.0 are not supported in upstream. So there is no need to carry code to support them. Signed-off-by:
-
Manivannan Sadhasivam authored
In both the functions, UFS_PHY_SOFT_RESET contains the mask of the reset bit. So this can be passed directly as the value to be written for asserting the reset. For deasserting, 0 can be passed. This gets rid of the FIELD_PREP() inside these functions and also UFS_PHY_RESET_{ENABLE/DISABLE} definitions. Signed-off-by: -
Manivannan Sadhasivam authored
In case the "core_clk_unipro" clock is not provided, "cycles_in_1us" variable will be used as uninitialized. So initialize it with 0. Issue reported by Smatch tool: drivers/ufs/host/ufs-qcom.c:1336 ufs_qcom_set_core_clk_ctrl() error: uninitialized symbol 'cycles_in_1us'. drivers/ufs/host/ufs-qcom.c:1341 ufs_qcom_set_core_clk_ctrl() error: uninitialized symbol 'cycles_in_1us'. Reviewed-by:
Nitin Rawat <quic_nitirawa@quicinc.com> Signed-off-by:
-
Manivannan Sadhasivam authored
Sort includes alphabetically. Reviewed-by:
-
Manivannan Sadhasivam authored
ufs_qcom_hosts array is assigned, but not used anywhere. So let's remove it. Reviewed-by:
-
Manivannan Sadhasivam authored
As done in other places, let's use dev_err_probe() to simplify the error handling while acquiring the device reset gpio using devm_gpiod_get_optional(). While at it, let's reword the error message to make it clear that the failure is due to acquiring "device reset gpio". Reviewed-by:
-
Manivannan Sadhasivam authored
devm_kzalloc() will itself print the error message on failure. So let's get rid of the redundant error message in ufs_qcom_init(). Signed-off-by:
-
Manivannan Sadhasivam authored
If ufs_qcom_power_up_sequence() fails, then it makes no sense to enable the lane clocks and continue ufshcd_hba_enable(). So let's check the return value of ufs_qcom_power_up_sequence(). Reviewed-by:
-
Manivannan Sadhasivam authored
Even though core_reset is optional, a failure during assert/deassert should be considered fatal, if core_reset is available. So fail ufs_qcom_power_up_sequence() if an error happens during reset and also get rid of the redundant warning as the ufs_qcom_host_reset() function itself prints error messages. Reviewed-by:
-
Manivannan Sadhasivam authored
Instead of duplicating the enable/disable IRQ part, let's export the helpers available in ufshcd driver and make use of them. This also fixes the possible redundant IRQ disable before asserting reset (when IRQ was already disabled). Fixes: 4a791574 ("scsi: ufs: ufs-qcom: Disable interrupt in reset path") Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Manivannan Sadhasivam authored
core_reset is optional, so there is no need to warn the user if it is not available. Reviewed-by:
-
Manivannan Sadhasivam authored
There are many instances where the variable assignments are not needed. Remove them. Reviewed-by:
-
Manivannan Sadhasivam authored
The return value should be -ENODEV indicating that the resource is not provided in DT, not -ENOMEM. Fix it! Fixes: c263b4ef ("scsi: ufs: core: mcq: Configure resource regions") Reviewed-by:
-
Manivannan Sadhasivam authored
Currently, the function returns -EINVAL if algorithm other than AES-256-XTS is requested. But the correct error code is -EOPNOTSUPP. Fix it! Cc: Abel Vesa <abel.vesa@linaro.org> Fixes: 56541c7c ("scsi: ufs: ufs-qcom: Switch to the new ICE API") Reviewed-by:
Abel Vesa <abel.vesa@linaro.org> Signed-off-by:
-
Manivannan Sadhasivam authored
Lane clock handling can be simplified by using the clk_bulk APIs. So let's make use of them. This also get's rid of the clock validation in the driver as kernel should just rely on the firmware (DT/ACPI) to provide the clocks required for proper functioning. Reviewed-by:
-
Nitin Rawat authored
Document the compatible string for the UFS found on SC7280. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Bao D. Nguyen <quic_nguyenb@quicinc.com> Acked-by:
Manivannan Sadhasivam <mani@kernel.org> Signed-off-by:
Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20231205-sc7280-ufs-v6-1-ad6ca7796de7@fairphone.comSigned-off-by:
-
Martin K. Petersen authored
Can Guo <quic_cang@quicinc.com> says: This series enables HS-G5 support on SM8550. This series is rebased on below changes from Mani - https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-1-manivannan.sadhasivam@linaro.org/ https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-2-manivannan.sadhasivam@linaro.org/ This series is tested on below HW combinations - SM8550 MTP + UFS4.0 SM8550 QRD + UFS3.1 SM8450 MTP + UFS3.1 (for regression test) SM8350 MTP + UFS3.1 (for regression test) Note that during reboot test on above platforms, I occasinally hit PA (PHY) error during the 2nd init, this is not related with this series. A fix for this is mentioned in below patchwork - https://patchwork.kernel.org/project/linux-scsi/patch/1698145815-17396-1-git-send-email-quic_ziqichen@quicinc.com/ Also note that on platforms, which have two sets of UFS PHY settings are provided (say G4 and no-G4, G5 and no-G5). The two sets of PHY settings are basically programming different values to different registers, mixing the two sets and/or overwriting one set with another set is definitely not blessed by UFS PHY designers. For SM8550, this series will make sure we honor the rule. However, for old targets Mani and I will fix them in another series in future. Link: https://lore.kernel.org/r/1701520577-31163-1-git-send-email-quic_cang@quicinc.comSigned-off-by:
-
Bao D. Nguyen authored
Start from HW ver 5, a spare register in UFS host controller is added and used to indicate the UFS device version. The spare register is populated by bootloader for now, but in future it will be populated by HW automatically during link startup with its best efforts in any boot stage prior to Linux. During host driver init, read the spare register, if it is not populated with a UFS device version, go ahead with the dual init mechanism. If a UFS device version is in there, use the UFS device version together with host controller's HW version to decide the proper PHY gear which should be used to configure the UFS PHY without going through the second init. Signed-off-by:
Can Guo <quic_cang@quicinc.com> Link: https://lore.kernel.org/r/1701520577-31163-9-git-send-email-quic_cang@quicinc.comReviewed-by:
-
Can Guo authored
In ufs_qcom_power_up_sequence(), check return value of phy_set_mode_ext() and stop proceeding if phy_set_mode_ext() fails. Reviewed-by:
-
Can Guo authored
Since HW ver 4, max HS gear can be get from UFS host controller's register, use the max HS gear as the initial PHY gear instead of UFS_HS_G2, so that we don't need to update the hard code for newer targets in future. Reviewed-by:
-
Can Guo authored
Qcom UFS hosts, with HW ver 5, can only support up to HS-G5 Rate-A due to HW limitations. If the HS-G5 PHY gear is used, update host_params->hs_rate to Rate-A, so that the subsequent power mode changes shall stick to Rate-A. Reviewed-by:
-
Can Guo authored
During host driver init, the phy_gear is set to the minimum supported gear (HS_G2). Then, during the first power mode change, the negotiated gear, say HS-G4, is updated to the phy_gear variable so that in the second init the updated phy_gear can be used to program the PHY. But the current code only allows update the phy_gear to a higher value. If one wants to start the first init with the maximum support gear, say HS-G4, the phy_gear is not updated to HS-G3 if the device only supports HS-G3. The original check added there is intend to make sure the phy_gear won't be updated when gear is scaled down (during clock scaling). Update the check so that one can start the first init with the maximum support gear without breaking the original fix by checking the ufshcd_state, that is, allow update to phy_gear only if power mode change is invoked from ufshcd_probe_hba(). Reviewed-by:
-
Can Guo authored
Setup host power mode and its limitations during UFS host driver init to avoid repetitive work during every power mode change. Acked-by:
-
Can Guo authored
In ufs_qcom_pwr_change_notify(), host_params.hs_rate has been set to PA_HS_MODE_B by ufshcd_init_host_param(), hence remove the duplicated line of work. Meanwhile, removed the macro UFS_QCOM_LIMIT_HS_RATE as it is only used here. Reviewed-by:
-
Can Guo authored
Structure ufs_dev_params is actually used in UFS host drivers to declare host specific power mode parameters, like ufs_<vendor>_params or host_cap, which makes the code not very straightforward to read. Rename the structure ufs_dev_params to ufs_host_params and unify the declarations in all drivers to host_params. In addition, rename the two functions ufshcd_init_pwr_dev_param() and ufshcd_get_pwr_dev_param() which work based on the ufs_host_params to ufshcd_init_host_params() and ufshcd_negotiate_pwr_params() respectively to avoid confusions. This change does not change any functionalities or logic. Acked-by:
Peter Wang <peter.wang@mediatek.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Signed-off-by:
-
Justin Stitt authored
Instead of copying @buf into a new buffer and carefully managing its newline/null-terminating status, we can just use sysfs_match_string() as it uses sysfs_streq() internally which handles newline/null-term: | /** | * sysfs_streq - return true if strings are equal, modulo trailing newline | * @s1: one string | * @s2: another string | * | * This routine returns true iff two strings are equal, treating both | * NUL and newline-then-NUL as equivalent string terminations. It's | * geared for use with sysfs input strings, which generally terminate | * with newlines but are compared against values without newlines. | */ | bool sysfs_streq(const char *s1, const char *s2) | ... Then entirely drop the now unused fcoe_parse_mode(), being careful to change if condition from checking for FIP_CONN_TYPE_UNKNOWN to < 0 as sysfs_match_string() can return -EINVAL. Also check explicitly if ctlr->mode is equal to FIP_CONN_TYPE_UNKNOWN -- this is probably preferred to "<=" as the behavior is more obvious while maintaining functionality. To get the compiler not to complain, make fip_conn_type_names const char * const. Perhaps, this should also be done for fcf_state_names. This also removes an instance of strncpy() which helps [1]. Link: https://github.com/KSPP/linux/issues/90 [1] Cc: <linux-hardening@vger.kernel.org> Signed-off-by:
Justin Stitt <justinstitt@google.com> Link: https://lore.kernel.org/r/20231212-strncpy-drivers-scsi-fcoe-fcoe_sysfs-c-v2-1-1f2d6b2fc409@google.comReviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Martin K. Petersen authored
Justin Tee <justintee8345@gmail.com> says: Update lpfc to revision 14.2.0.17 This patch set contains bug fixes for the VMID feature. The patches were cut against Martin's 6.8/scsi-queue tree. Link: https://lore.kernel.org/r/20231207224039.35466-1-justintee8345@gmail.comSigned-off-by:
-
Justin Tee authored
Update lpfc version to 14.2.0.17 Signed-off-by:
Justin Tee <justin.tee@broadcom.com> Link: https://lore.kernel.org/r/20231207224039.35466-5-justintee8345@gmail.comSigned-off-by:
-
Justin Tee authored
If priority tagging is set in the service parameters of a FLOGI cmpl, then we update the vmid_flag. In the current logic, if a follow up FLOGI cmpl updates its service parameters such that priority tagging is no longer set, then the vmid_flag ends up keeping stale data. Fix by ensuring we clear the vmid_flag member during lpfc_reinit_vmid, and check the priority tagging service parameter after reinitialization of the vmid data structures. Signed-off-by:
-
Justin Tee authored
After a follow up FDISC cmpl, an NPIV's VMID data structures are not updated. Fix by calling lpfc_reinit_vmid and copying the physical port's vmid_flag to the NPIV's vmid_flag in the NPIV registration cmpl code path. Signed-off-by:
-
Justin Tee authored
VMID driver support is a load time configuration setting. Thus, change sysfs attributes to read only. Signed-off-by:
-
Martin K. Petersen authored
Karan Tilak Kumar <kartilak@cisco.com> says: Hi Martin, reviewers, This cover letter describes the feature: add support for multiqueue (MQ) to fnic driver. Background: The Virtual Interface Card (VIC) firmware exposes several queues that can be configured for sending IOs and receiving IO responses. Unified Computing System Manager (UCSM) and Intersight Manager (IMM) allows users to configure the number of queues to be used for IOs. The number of IO queues to be used is stored in a configuration file by the VIC firmware. The fNIC driver reads the configuration file and sets the number of queues to be used. Previously, the driver was hard-coded to use only one queue. With this set of changes, the fNIC driver will configure itself to use multiple queues. This feature takes advantage of the block multiqueue layer to parallelize IOs being sent out of the VIC card. Here's a brief description of some of the salient patches: - vnic_scsi.h needs to be in sync with VIC firmware to be able to read the number of queues from the firmware config file. A patch has been created for this. - In an environment with many fnics (like we see in our customer environments), it is hard to distinguish which fnic is printing logs. Therefore, an fnic number has been included in the logs. - read the number of queues from the firmware config file. - include definitions in fnic.h to support multiqueue. - modify the interrupt service routines (ISRs) to read from the correct registers. The numbers that are used here come from discussions with the VIC firmware team. - track IO statistics for different queues. - remove usage of host_lock, and only use fnic_lock in the fnic driver. - use a hardware queue based spinlock to protect io_req. - replace the hard-coded zeroth queue with a hardware queue number. This presents a bulk of the changes. - modify the definition of fnic_queuecommand to accept multiqueue tags. - improve log messages, and indicate fnic number and multiqueue tags for effective debugging. Even though the patches have been made into a series, some patches are heavier than others. But, every effort has been made to keep the purpose of each patch as a single-purpose, and to compile cleanly. This patchset has been tested as a whole. Therefore, the tested-by fields have been added only to two patches in the set. All the individual patches compile cleanly. However, I've refrained from adding tested-by to most of the patches, so as to not mislead the reviewer/reader. A brief note on the unit tests: 1. Increase number of queues to 64. Load driver. Run IOs via Medusa. 12+ hour run successful. 2. Configure multipathing, and run link flaps on single link. IOs drop briefly, but pick up as expected. 3. Configure multipathing, and run link flaps on two links, with a 30 second delay in between. IOs drop briefly, but pick up as expected. Repeat the above tests with 1 queue and 32 queues. All tests were successful. Please consider this patch series for the next merge window. Link: https://lore.kernel.org/r/20231211173617.932990-1-kartilak@cisco.comSigned-off-by:
-
Karan Tilak Kumar authored
Increment driver version for multiqueue (MQ). Reviewed-by:
Sesidhar Baddela <sebaddel@cisco.com> Reviewed-by:
Arulprabhu Ponnusamy <arulponn@cisco.com> Signed-off-by:
Karan Tilak Kumar <kartilak@cisco.com> Link: https://lore.kernel.org/r/20231211173617.932990-14-kartilak@cisco.comSigned-off-by:
-
Karan Tilak Kumar authored
Improve existing logs by adding fnic number, hardware queue, tag, and mqtag in the prints. Add logs with the above elements for effective debugging. Reviewed-by:
-
Karan Tilak Kumar authored
Implement support for MQ in fnic driver: The block multiqueue layer issues IO to the fnic driver with an MQ tag. Use the mqtag and derive a tag from it. Derive the hardware queue from the mqtag and use it in all paths. Modify queuecommand to handle mqtag. Replace wq and cq indices to support MQ. Replace the zeroth queue with a hardware queue. Implement spin locks on a per hardware queue basis. Replace io_lock with per hardware queue spinlock. Implement out of range tag checks. Allocate an io_req_table to track status of the io_req. Test the driver by building it, loading it, and configuring 64 queues in UCSM. Issue IOs using Medusa on multiple fnics. Enable/disable links to exercise the abort and clean up path. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310300032.2awCqkfn-lkp@intel.com/Reviewed-by:
-
Karan Tilak Kumar authored
Set map_queues in the fnic_host_template to fnic_mq_map_queues_cpus. Define fnic_mq_map_queues_cpus to set cpu assignment to fnic queues. Refactor code in fnic_probe to enable vnic queues before scsi_add_host. Modify notify set to the correct index. Reviewed-by:
John Garry <john.g.garry@oracle.com> Signed-off-by:
-
Karan Tilak Kumar authored
Remove usage of host_lock. Replace with fnic_lock, where necessary. fnic does not use host_lock. fnic uses fnic_lock. Use fnic lock to protect fnic members in fnic_queuecommand. Add log messages in error cases. Reviewed-by:
-
