Re: [PATCH v2] ufs: sysfs: fix current_power_mode read without SSU

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] ufs: missing error recovery when hibern8_enter fails leaves link active
- [Low] cleanup: mixing goto-based error handling and scope-based cleanup
--

commit 7f21a836a7974ab0a73d76e4107550f8d10d5c90
Author: robelin <robelin@nvidia.com>

ufs: sysfs: fix current_power_mode read without SSU

This commit introduces a dedicated sysfs show function for current_power_mode
to query the power mode attribute without fully resuming the UFS device to
the Active state. It handles exiting and re-entering the Hibern8 state
directly to avoid sending START STOP UNIT commands that would wake the device.

> diff --git a/drivers/ufs/core/ufs-sysfs.c b/drivers/ufs/core/ufs-sysfs.c
> index cf49ad0258e14..2d1ed2ca0dfa4 100644
> --- a/drivers/ufs/core/ufs-sysfs.c
> +++ b/drivers/ufs/core/ufs-sysfs.c
[ ... ]
> @@ -1786,7 +1786,79 @@ out:									\
>  static DEVICE_ATTR_RO(_name)
>  
>  UFS_ATTRIBUTE(boot_lun_enabled, _BOOT_LU_EN);
> -UFS_ATTRIBUTE(current_power_mode, _POWER_MODE);
> +
> +/*
> + * Per UFS spec, bCurrentPowerMode is the only attribute the device must
> + * respond to in any power mode.  Read it without waking the device to
> + * Active.
> + */
> +static ssize_t current_power_mode_show(struct device *dev,
> +	struct device_attribute *attr, char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +	bool exited_h8 = false;
> +	u32 value;
> +	int ret = 0;
> +
> +	down(&hba->host_sem);
> +	if (!ufshcd_is_user_access_allowed(hba)) {
> +		ret = -EBUSY;
> +		goto out_unlock;
> +	}
> +
> +	pm_runtime_get_sync(hba->dev);
> +
> +	ufshcd_hold(hba);
> +	scoped_guard(ufshcd_wl_pm, hba) {

[Severity: Low]
Is it intentional to mix goto-based error handling (like the goto out_unlock
above) and scope-based cleanup helpers (scoped_guard) in the same function?

The subsystem guidelines for cleanup functions recommend either converting all
resources that need a cleanup to scope-based cleanup, or converting none of
them, to avoid confusing ownership semantics.

> +		if (ufshcd_is_link_off(hba) || ufshcd_is_ufs_dev_poweroff(hba)) {
> +			/*
> +			 * Device is powered down (rpm_lvl 4/5) or link is off
> +			 * (rpm_lvl 5/6): nothing to query until a full resume.
> +			 */
> +			ret = -EINVAL;
> +			break;
> +		}
> +
> +		if (ufshcd_is_link_hibern8(hba)) {
> +			ret = ufshcd_uic_hibern8_exit(hba);
> +			if (ret) {
> +				dev_err(hba->dev, "%s: hibern8 exit failed %d\n",
> +					__func__, ret);
> +				break;
> +			}
> +			ufshcd_set_link_active(hba);
> +			exited_h8 = true;
> +		}
> +
> +		ret = ufshcd_query_attr(hba, UPIU_QUERY_OPCODE_READ_ATTR,
> +			QUERY_ATTR_IDN_POWER_MODE, 0, 0, &value);
> +
> +		if (exited_h8) {
> +			int h8_ret = ufshcd_uic_hibern8_enter(hba);
> +
> +			if (h8_ret) {
> +				dev_err(hba->dev, "%s: hibern8 enter failed %d\n",
> +					__func__, h8_ret);
> +				ret = h8_ret;
> +			} else {
> +				ufshcd_set_link_hibern8(hba);
> +			}

[Severity: High]
Does this code leave the UFS link in UIC_LINK_ACTIVE_STATE if
ufshcd_uic_hibern8_enter() fails?

If h8_ret is an error, this path returns the error without restoring the
link state or triggering error recovery. Since the WLUN remains suspended,
this can lead to the host controller runtime suspending and blindly turning off
the host clocks while the UFS link is still active. This violates hardware
constraints and guarantees a 10s command timeout on the next I/O.

> +		}
> +	}
> +	ufshcd_release(hba);
> +	pm_runtime_put_sync(hba->dev);
> +
> +	if (!ret)
> +		ret = sysfs_emit(buf, "0x%08X\n", value);
> +	else
> +		ret = -EINVAL;
> +
> +out_unlock:
> +	up(&hba->host_sem);
> +	return ret;
> +}
> +static DEVICE_ATTR_RO(current_power_mode);
> +
[ ... ]
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 234e18b5078f2..462749b850b13 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -10319,7 +10319,8 @@ static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  	enum ufs_dev_pwr_mode req_dev_pwr_mode;
>  	enum uic_link_state req_link_state;
>  
> -	hba->pm_op_in_progress = true;
> +	guard(ufshcd_wl_pm)(hba);
> +

[Severity: Low]
Does this introduce scope-based cleanup into __ufshcd_wl_suspend(), a function
that heavily relies on goto labels for error handling?

__ufshcd_wl_suspend() has multiple error paths using goto vops_suspend,
goto enable_scaling, and goto out. Mixing goto-based error handling and
scope-based cleanup helpers in the same function can lead to confusing
ownership semantics and is generally discouraged by the subsystem guidelines.

>  	if (pm_op != UFS_SHUTDOWN_PM) {
>  		pm_lvl = pm_op == UFS_RUNTIME_PM ?
>  			 hba->rpm_lvl : hba->spm_lvl;
[ ... ]
> @@ -10500,9 +10500,11 @@ static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  {
>  	int ret;
> -	enum uic_link_state old_link_state = hba->uic_link_state;
> +	enum uic_link_state old_link_state;
> +
> +	guard(ufshcd_wl_pm)(hba);
>  
> -	hba->pm_op_in_progress = true;
> +	old_link_state = hba->uic_link_state;

[Severity: Low]
Similar to __ufshcd_wl_suspend(), does this mix scope-based cleanup with
existing goto-based error jumps in __ufshcd_wl_resume()?

>  
>  	/*
>  	 * Call vendor specific resume callback. As these callbacks may access

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915145534.8517-1-s921975628@gmail.com?part=1