Re: [PATCH V1 2/2] arm64: dts: qcom: Set specified gear configuration for Hamoa

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incorrect fallback logic when DT-specified `opp-level` exceeds the negotiated maximum gear.
--

commit 1074dd135232851ffc9d0417dea7de1323a012a4
Author: Nitin Rawat <nitin.rawat@oss.qualcomm.com>

arm64: dts: qcom: Set specified gear configuration for Hamoa

Assign the appropriate UFS HS gear speed levels to each OPP frequency
entry in the device tree, enabling proper per-frequency gear
scaling (G1 at 75MHz, G3 at 150MHz, G5 at 300MHz).

> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index 4ba751a65142b..bc7383937a293 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
[ ... ]
> @@ -3992,6 +3994,7 @@ opp-300000000 {
>  						 /bits/ 64 <0>,
>  						 /bits/ 64 <0>,
>  						 /bits/ 64 <0>;
> +					opp-level = <5>; /* HS-G5 */

[Severity: High]
Will adding this HS-G5 opp-level break devfreq gear scaling if the host is
paired with a slower UFS memory device, such as one with a maximum of G4?

Looking at ufs_qcom_freq_to_gear_speed() in drivers/ufs/host/ufs-qcom.c, the
retrieved opp-level is checked against the negotiated maximum gear:

    gear = dev_pm_opp_get_level(dev, freq);
    /* ... */
    /*
     * Greater than max gear means that there is no specified gear configured
     * in DT or the specified gear is invalid.
     */
    if (gear <= hba->max_pwr_info.info.gear_rx)
        return gear;

    gear = UFS_HS_DONT_CHANGE;

If this DT configures a gear level of 5 (HS-G5), but the attached UFS device
only supports gear 4 (HS-G4), the check `5 <= 4` evaluates to false.

Because dev_pm_opp_get_level() returns OPP_LEVEL_UNSET (U32_MAX) when the
property is missing, the code seems to conflate a missing property with a
gear that simply exceeds the attached device's maximum capability.

When the check fails, instead of capping the gear to the device's maximum,
the code falls through to the legacy hardcoded switch block. If the new
frequency is missing from that legacy block, it hits the default case, logs
an "Unsupported clock freq" error, and fails to scale entirely.

Does ufs_qcom_freq_to_gear_speed() need to explicitly check against
OPP_LEVEL_UNSET and cap the DT gear to the negotiated maximum instead of
falling back to the legacy behavior?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260829074355.946543-1-nitin.rawat@oss.qualcomm.com?part=2