On Wed, 2022-12-21 at 08:00 +1100, Daniil Lunev wrote: > > Applied to 6.2/scsi-staging, thanks! > > There is an interesting side effect of the patch in this iteration > (which I am not sure was present in the past iteration I tried): > If the device auto suspends while running purge - controller is > seemingly recent and thus the purge is aborted (with no patch at all > it hangs). > That might be ok behaviour though - it will just make it an explicit > requirement to disable runtime suspend during the management > operation. > Hi Daniil, I am not sure if this is similar reason we get SSU(sleep) fail. But if without this patch when purge is onging, system IO will hang, this is no better. And I have another idea about rpm and purge. To disable runtime suspend when purge operation is ongoing: 1. Disable rpm when fPurgeEnable is set, polling bPurgeStatus become 0 and enable rpm. But polling bPurgeStatus will extend rpm timer, so we don't need really disable rpm, right? 2. Check bPurgeStatus if enter runtime suspend, return EBUSY if bPurgeStatus is not 0 to break suspend. This is correct design to tell rpm flamework that driver is busy with purge and suspend is inappropriate. But it should be similar as current flow, return EBUSY when get SSU fail? So, with current design, if purge initiator do not want to see rpm EBUSY, then he should polling bPurgeStatus. What do you think? Thanks. BR Peter > localhost ~ # ufs-utils fl -t 6 -e -p /dev/bsg/ufs-bsg0 > localhost ~ # ufs-utils attr -a -p /dev/bsg/ufs-bsg0 | grep > bPurgeStatus > bPurgeStatus := 0x00 > > [ 25.801980] ufs_device_wlun 0:0:0:49488: START_STOP failed for > power mode: 2, result 2 > [ 25.802002] ufs_device_wlun 0:0:0:49488: Sense Key : Not Ready > [current] > [ 25.802009] ufs_device_wlun 0:0:0:49488: Add. Sense: No additional > sense information > [ 25.802020] ufs_device_wlun 0:0:0:49488: ufshcd_wl_runtime_suspend > failed: -16
