RE: [PATCH v1] scsi: ufs: Avoid runtime suspend possibly being blocked forever

[Stanley Chu <stanley.chu@mediatek.com>]

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



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel