Re: [PATCH v1] ufs: core: wlun suspend SSU fail recovery

["Peter Wang (王信友)" <peter.wang@mediatek.com>]

On Wed, 2022-11-30 at 12:17 +0200, Adrian Hunter wrote:
> On 1/11/22 16:24, peter.wang@mediatek.com wrote:
> > From: Peter Wang <peter.wang@mediatek.com>
> > 
> > When SSU fail in wlun suspend flow, trigger error handlder and
> 
> handlder -> handler

will fix next versio, thanks.

> 
> Why / how does SSU fail?
> 

Unknow, it is seldom and we cannot catch fail the failure scenarios. We
suspect is maybe the device problem which response wrong sense code.
So, I think the driver is better to cover this error.
Here is our cmd histroy log with 3 times SSU fail, and retrun busy to
do error handler.

 26-c(1),  2576.085601525, 9396,18, rs, ret=-16, time_us=   41136,
pwr_mode=1, link_status=1
 25-r(1),  2576.085027371, 9396,
1,0x1b,t=53,db:0x       0,is:0x   80000,crypt:0,0,lba=         0,len=  
  -1,	31308
 24-r(1),  2576.084996910, 9396,
0,0x1b,t=53,db:0x       0,is:0x   80000,crypt:0,0,lba=         0,len=  
  -1,	0
 23-r(1),  2576.084919679, 9396,
1,0x1b,t=52,db:0x       0,is:0x   80000,crypt:0,0,lba=         0,len=  
  -1,	32846
 22-r(1),  2576.084887679, 9396,
0,0x1b,t=52,db:0x       0,is:0x   80000,crypt:0,0,lba=         0,len=  
  -1,	0
 21-r(1),  2576.084704295,    0,
1,0x1b,t=55,db:0x       0,is:0x   80000,crypt:0,0,lba=         0,len=  
  -1,	39777539
 20-r(1),  2576.044927679, 9396,
0,0x1b,t=55,db:0x       0,is:0x   80000,crypt:0,0,lba=         0,len=  
  -1,	0


> > return busy to break the suspend.
> > If not, wlun runtime pm status become error and the consumer will
> > stuck in runtime suspend status.
> > 
> > Signed-off-by: Peter Wang <peter.wang@mediatek.com>
> > ---
> >  drivers/ufs/core/ufshcd.c | 16 +++++++++++++++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> > index b1f59a5fe632..2f2d3d5d8684 100644
> > --- a/drivers/ufs/core/ufshcd.c
> > +++ b/drivers/ufs/core/ufshcd.c
> > @@ -8970,6 +8970,7 @@ static int __ufshcd_wl_suspend(struct ufs_hba
> > *hba, enum ufs_pm_op pm_op)
> >  	enum ufs_pm_level pm_lvl;
> >  	enum ufs_dev_pwr_mode req_dev_pwr_mode;
> >  	enum uic_link_state req_link_state;
> > +	unsigned long flags;
> >  
> >  	hba->pm_op_in_progress = true;
> >  	if (pm_op != UFS_SHUTDOWN_PM) {
> > @@ -9049,8 +9050,21 @@ static int __ufshcd_wl_suspend(struct
> > ufs_hba *hba, enum ufs_pm_op pm_op)
> >  
> >  		if (!hba->dev_info.b_rpm_dev_flush_capable) {
> >  			ret = ufshcd_set_dev_pwr_mode(hba,
> > req_dev_pwr_mode);
> > -			if (ret)
> > +			if (ret) {
> > +				/*
> > +				 * If retrun err in suspend flow, IO
> > will hang.
> 
> retrun -> return

will fix next version, thanks

> 
> > +				 * Trigger error handler and break
> > suspend for
> > +				 * error recovery.
> > +				 */
> > +				spin_lock_irqsave(hba->host->host_lock, 
> > flags);
> > +				hba->force_reset = true;
> > +				ufshcd_schedule_eh_work(hba);
> 
> __ufshcd_wl_suspend() is also used for shutdown and poweroff
> where scheduling EH is not appropriate.

Will check pm_op and bypass UFS_SHUTDOWN_PM next version, thanks.

> 
> > +				spin_unlock_irqrestore(hba->host-
> > >host_lock,
> > +					flags);
> > +
> > +				ret = -EBUSY;
> >  				goto enable_scaling;
> > +			}
> >  		}
> >  	}
> >  
> 
>