- 19 Dec, 2023 2 commits
-
-
Manivannan Sadhasivam authored
While cleaning up the code to use ufshcd_rmwl() helper, the ESI vector mask was changed incorrectly. Fix it and also define a proper macro for the value together with FIELD_PREP(). Reported-by:
Andrew Halaney <ahalaney@redhat.com> Fixes: 0e9f4375 ("scsi: ufs: qcom: Use ufshcd_rmwl() where applicable") Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20231214125532.55109-1-manivannan.sadhasivam@linaro.orgReviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Martin K. Petersen authored
Commit fa3dca82 ("scsi: ufs: host: Rename structure ufs_dev_params to ufs_host_params") inadvertently introduced a comment line without '*' prefix. Format the comment section correctly. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312171915.YhlTLvLL-lkp@intel.com/ Fixes: fa3dca82 ("scsi: ufs: host: Rename structure ufs_dev_params to ufs_host_params") Signed-off-by:
-
- 14 Dec, 2023 38 commits
-
-
Martin K. Petersen authored
chenxiang <chenxiang66@hisilicon.com> says: This series contain some fixes and cleanups including: - Set .phy_attached before notifying phyup event HISI_PHYEE_PHY_UP_PM; - Use standard error code instead of hardcode; - Check before using pointer variable; - Rollback some operations if FLR failed; - Correct the number of global debugfs registers; Link: https://lore.kernel.org/r/1702525516-51258-1-git-send-email-chenxiang66@hisilicon.comSigned-off-by:
-
Yihang Li authored
In function debugfs_debugfs_snapshot_global_reg_v3_hw() it uses debugfs_axi_reg.count (which is the number of axi debugfs registers) to acquire the number of global debugfs registers. Use debugfs_global_reg.count to acquire the number of global debugfs registers instead. Fixes: 623a4b6d ("scsi: hisi_sas: Move debugfs code to v3 hw driver") Signed-off-by:
Yihang Li <liyihang9@huawei.com> Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Link: https://lore.kernel.org/r/1702525516-51258-6-git-send-email-chenxiang66@hisilicon.comSigned-off-by:
-
Yihang Li authored
We obtain the semaphore and set HISI_SAS_RESETTING_BIT in hisi_sas_reset_prepare_v3_hw(), block the scsi host and set HISI_SAS_REJECT_CMD_BIT in hisi_sas_controller_reset_prepare(), released them in hisi_sas_controller_reset_done(). However, if the HW reset failure in FLR results in early return, the semaphore and flag bits will not be release. Rollback some operations including clearing flags / releasing semaphore when FLR is failed. Fixes: e5ea4801 ("scsi: hisi_sas: Implement handlers of PCIe FLR for v3 hw") Signed-off-by:
-
Yihang Li authored
In commit 4b329abc ("scsi: hisi_sas: Move slot variable definition in hisi_sas_abort_task()"), we move the variables slot to the function head. However, the variable slot may be NULL, we should check it in each branch. Fixes: 4b329abc ("scsi: hisi_sas: Move slot variable definition in hisi_sas_abort_task()") Signed-off-by:
-
Yihang Li authored
In function hisi_sas_controller_prereset(), -ENOSYS (Function not implemented) should be returned if the driver does not support .soft_reset. Returns -EPERM (Operation not permitted) if HISI_SAS_RESETTING_BIT is already be set. In function _suspend_v3_hw(), returns -EPERM (Operation not permitted) if HISI_SAS_RESETTING_BIT is already be set. Fixes: 4522204a ("scsi: hisi_sas: tidy host controller reset function a bit") Signed-off-by:
-
Yihang Li authored
Currently in directly attached scenario, the phyup event HISI_PHYE_PHY_UP_PM is notified before .phy_attached is set - this may cause the phyup work hisi_sas_bytes_dmaed() execution failed and the attached device will not be found. To fix it, set .phy_attached before notifing phyup event. Signed-off-by:
-
Martin K. Petersen authored
Bean Huo <beanhuo@iokpp.de> says: Adding RTC support for embedded storage device UFS in its driver, it is important for a few key reasons: 1. Helps with Regular Maintenance: The RTC provides a basic way to keep track of time, making it useful for scheduling routine maintenance tasks in the storage device. This includes things like making sure data is spread evenly across the storage to extend its life. 2. Figuring Out How Old Data Is: The RTC helps the device estimate how long ago certain parts of the storage were last used. This is handy for deciding when to do maintenance tasks to keep the storage working well over time. 3. Making Devices Last Longer: By using the RTC for regular upkeep, we can make sure the storage device lasts longer and stays reliable. This is especially important for devices that need to work well for a long time. 4.Fitting In with Other Devices: The inclusion of RTC support aligns with existing UFS specifications (starting from UFS Spec 2.0) and is consistent with the prevalent industry practice. Many UFS devices currently on the market utilize RTC for internal timekeeping. By ensuring compatibility with this widely adopted standard, the embedded storage device becomes seamlessly integrable with existing hardware and software ecosystems, reducing the risk of compatibility issues. In short, adding RTC support to embedded storage device UFS helps with regular upkeep, extends the device's life, ensures compatibility, and keeps everything running smoothly with the rest of the system. Link: https://lore.kernel.org/r/20231212220825.85255-1-beanhuo@iokpp.deSigned-off-by:
-
Bean Huo authored
Introduce a sysfs node named 'rtc_update_ms' within the kernel, enabling user to adjust the RTC periodic update frequency to suit the specific requirements of the system and UFS. Also, this patch allows the user to disable/enable periodic update RTC in the UFS idle time. Signed-off-by:
Bean Huo <beanhuo@micron.com> Link: https://lore.kernel.org/r/20231212220825.85255-4-beanhuo@iokpp.deAcked-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Thomas Weißschuh <linux@weissschuh.net> Signed-off-by:
-
Bean Huo authored
Add Real Time Clock (RTC) support for UFS device. This enhancement is crucial for the internal maintenance operations of the UFS device. The patch enables the device to handle both absolute and relative time information. Furthermore, it includes periodic task to update the RTC in accordance with the UFS Spec, ensuring the accuracy of RTC information for the device's internal processes. RTC and qTimestamp serve distinct purposes. The RTC provides a coarse level of granularity with, at best, approximate single-second resolution. This makes the RTC well-suited for the device to determine the approximate age of programmed blocks after being updated by the host. On the other hand, qTimestamp offers nanosecond granularity and is specifically designed for synchronizing Device Error Log entries with corresponding host-side logs. Given that the RTC has been a standard feature since UFS Spec 2.0, and qTimestamp was introduced in UFS Spec 4.0, the majority of UFS devices currently on the market rely on RTC. Therefore, it is advisable to continue supporting RTC in the Linux kernel. This ensures compatibility with the prevailing UFS device implementations and facilitates seamless integration with existing hardware. By maintaining support for RTC, we ensure broad compatibility and avoid potential issues arising from deviations in device specifications across different UFS versions. Signed-off-by:
Mike Bi <mikebi@micron.com> Signed-off-by:
Luca Porzio <lporzio@micron.com> Link: https://lore.kernel.org/r/20231212220825.85255-3-beanhuo@iokpp.deAcked-by:
-
Bean Huo authored
Add helper inline for retrieving whether UFS device is busy or not. Signed-off-by:
-
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:
-
Manivannan Sadhasivam authored
Remove unused definitions. 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:
-
