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