Re: [PATCH 0/5] scsi: ufs: Fix device management timeouts and runtime PM errors

[Stanley Jhu]

On 10/26/26 4:26 PM, Bart Van Assche wrote:
> Patches 3/5 - 5/5 introduce a behavior change: a failed runtime suspend
> sets power.runtime_error but leaves the W-LUN in the RPM_ACTIVE state.
> Today, sysfs, BSG and hwmon accesses still work in that state. With this
> series they all fail with -EINVAL until the error handler's
> ufshcd_recover_pm_error() clears the flag. Is this behavior change
> intentional?

Thanks for catching this. The v1 cover letter and commit messages were
wrong to claim that a failed W-LUN runtime suspend latches
power.runtime_error.

In __ufshcd_wl_suspend(), every runtime suspend failure path
(ufshcd_bkops_ctrl(), ufshcd_set_dev_pwr_mode() and
ufshcd_link_state_transition()) schedules error recovery and sets
ret = -EBUSY. The vendor vops->suspend callbacks return 0, -EBUSY or
-EAGAIN. rpm_suspend() only sets dev->power.runtime_error when retval is
neither -EBUSY nor -EAGAIN, so a failed W-LUN runtime suspend leaves
power.runtime_error at 0 and runtime_status at RPM_ACTIVE. In that state
pm_runtime_resume_and_get() returns 0 and sysfs, BSG and hwmon accesses
keep working as before.

I checked this on QEMU, with and without this series, in SDB and MCQ
modes, by failing ufshcd_set_dev_pwr_mode() during W-LUN runtime
suspend. rpm_suspend() returned -EBUSY, runtime_error stayed 0, and
sysfs, BSG and debugfs accesses all succeeded.

pm_runtime_resume_and_get() only returns an error when the W-LUN is not
RPM_ACTIVE and runtime resume fails, or when runtime PM is disabled
while the W-LUN is suspended. I will send a v2 that drops the incorrect
runtime_error claim from the cover letter and commit messages.