These limits were always defined as 0, but that didn't cause any issue
since the driver had hardcoded limits. In commit b4e13e1ae95e ("scsi: ufs:
qcom: Add multiple frequency support for MAX_CORE_CLK_1US_CYCLES") the
hardcoded limits were removed and the driver started reading them from DT,
causing UFS to stop working on MSM8996. Add real UniPro clock limits to fix
UFS.
Signed-off-by: Yassine Oudjana <[email protected]>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 13667886f50a..4f9939b13c3c 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -2064,7 +2064,7 @@ ufshc: ufshc@624000 {
<0 0>,
<0 0>,
<150000000 300000000>,
- <0 0>,
+ <75000000 150000000>,
<0 0>,
<0 0>,
<0 0>,
--
2.43.0
On 18.12.2023 14:39, Yassine Oudjana wrote:
> These limits were always defined as 0, but that didn't cause any issue
> since the driver had hardcoded limits. In commit b4e13e1ae95e ("scsi: ufs:
> qcom: Add multiple frequency support for MAX_CORE_CLK_1US_CYCLES") the
> hardcoded limits were removed and the driver started reading them from DT,
> causing UFS to stop working on MSM8996. Add real UniPro clock limits to fix
> UFS.
>
> Signed-off-by: Yassine Oudjana <[email protected]>
> ---
Fixes: 57fc67ef0d35 ("arm64: dts: qcom: msm8996: Add ufs related nodes")
Reviewed-by: Konrad Dybcio <[email protected]>
Konrad
On Mon, Dec 18, 2023 at 01:39:42PM +0000, Yassine Oudjana wrote:
> These limits were always defined as 0, but that didn't cause any issue
> since the driver had hardcoded limits. In commit b4e13e1ae95e ("scsi: ufs:
> qcom: Add multiple frequency support for MAX_CORE_CLK_1US_CYCLES") the
> hardcoded limits were removed and the driver started reading them from DT,
> causing UFS to stop working on MSM8996. Add real UniPro clock limits to fix
> UFS.
>
Such driver changes are not acceptable, as they break backwards
compatibility with existing DeviceTree.
Can you please try to fix the driver to handle this case?
After that is done, I'd be happy to take this patch.
Thanks,
Bjorn
> Signed-off-by: Yassine Oudjana <[email protected]>
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 13667886f50a..4f9939b13c3c 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -2064,7 +2064,7 @@ ufshc: ufshc@624000 {
> <0 0>,
> <0 0>,
> <150000000 300000000>,
> - <0 0>,
> + <75000000 150000000>,
> <0 0>,
> <0 0>,
> <0 0>,
> --
> 2.43.0
>
>
On Mon, 18 Dec 2023 13:39:42 +0000, Yassine Oudjana wrote:
> These limits were always defined as 0, but that didn't cause any issue
> since the driver had hardcoded limits. In commit b4e13e1ae95e ("scsi: ufs:
> qcom: Add multiple frequency support for MAX_CORE_CLK_1US_CYCLES") the
> hardcoded limits were removed and the driver started reading them from DT,
> causing UFS to stop working on MSM8996. Add real UniPro clock limits to fix
> UFS.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: msm8996: Define UFS UniPro clock limits
commit: 68c4c20848d71b0e69c3403becb5dd23e89e5896
Best regards,
--
Bjorn Andersson <[email protected]>