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

[Peter Wang (王信友)]

On Fri, 2022-12-02 at 10:32 +1100, Daniil Lunev wrote:
> On Thu, Dec 1, 2022 at 4:50 AM Bart Van Assche <bvanassche at acm.org>
> wrote:
> > 
> > On 11/30/22 02:17, Adrian Hunter wrote:
> > > On 1/11/22 16:24, peter.wang at mediatek.com wrote:
> > > > From: Peter Wang <peter.wang at mediatek.com>
> > > > 
> > > > When SSU fail in wlun suspend flow, trigger error handlder and
> > > 
> > > handlder -> handler
> > > 
> > > Why / how does SSU fail?
> > 
> > I'm not sure but the issue that Peter is trying to fix with this
> > patch
> > may already have been fixed by my patch series "Fix a deadlock in
> > the
> > UFS driver".
> 
> We observe a similar failure scenario when a device tries to change
> power mode (e.g. due to autosuspend) while "purge" is in progress. It
> appears that in this case the "pm_only" counter is increased on the
> device queue prior to the attempt of entering a runtime suspended
> state, but not reduced upon it failing due to the device being busy
> with an ongoing purge. That leads to a deadlock of subsequent IO
> operations to the device.
> 
> --Daniil

Hi Daniil,

May I have a question, which dievce you use in this failure scenario?  
I think it is same issue due to SSU fail, and wlun devcie pm enter
error state. So the cunsomer(scsi lu device) is block in suspend state
and connot resume to reduce pm_only lead to IO hang.

Thanks.
BR
Peter