Hi Avri,
On Wed, 2019-06-12 at 11:10 +0000, Avri Altman wrote:
Hi,
UFS runtime suspend can be triggered after pm_runtime_enable() is invoked in ufshcd_pltfrm_init(). However if the first runtime suspend is triggered before binding ufs_hba structure to ufs device structure via platform_set_drvdata(), then UFS runtime suspend will be no longer triggered in the future because its dev->power.runtime_error was set in the first triggering and does not have any chance to be cleared.
To be more clear, dev->power.runtime_error is set if hba is NULL in ufshcd_runtime_suspend() which returns -EINVAL to rpm_callback() where dev->power.runtime_error is set as -EINVAL. In this case, any future rpm_suspend() for UFS device fails because rpm_check_suspend_allowed() fails due to non-zero dev->power.runtime_error.
To resolve this issue, make sure the first UFS runtime suspend get valid "hba" in ufshcd_runtime_suspend(): Enable UFS runtime PM only after hba is successfully bound to UFS device structure.
Fixes: e3ce73d (scsi: ufs: fix bugs related to null pointer access and array size)
This code was inserted before platform_set_drvdata in 6269473 [SCSI] ufs: Add runtime PM support for UFS host controller driver. Why do you point to e3ce73d?
e3ce73d (scsi: ufs: fix bugs related to null pointer access and array size) changed the returned value from 0 to -EINVAL in case of NULL "hba" in ufshcd_runtime_suspend().
But you are right, above patch may do the right thing, and the real root cause is the incorrect timing of pm_runtime_enable().
I will fix commit message in next version.
Thanks, Avri
Thanks. Stanley