Hi Stanley, I am aware that this discussion is already concluded, Just pointing out a small issue that might ease your mind further. Thanks, Avri > > Hi Can, > > On Tue, 2019-12-31 at 16:35 +0800, Can Guo wrote: > > > Hi Stanley, > > > > I missed this mail before I hit send. In current code, as per my > > understanding, UFS device's power state should be Active after > > ufshcd_link_startup() returns. > > If I am wrong, please feel free to correct me. > > > > Yes, this assumption of ufshcd_probe_hba() is true so I will drop this patch. > Thanks for remind. > > > Due to you are almost trying to revert commit 7caf489b99a42a, I am > > just wondering if you encounter failure/error caused by it. > > Yes, we actually have some doubts from the commit message of "scsi: ufs: > issue link startup 2 times if device isn't active" > > If we configured system suspend as device=PowerDown/Link=LinkDown mode, > during resume, the 1st link startup will be successful, and after that device could > be accessed normally so it shall be already in Active power mode. We did not > find devices which need twice linkup for normal work. > > And because the 1st linkup is OK, the forced 2nd linkup by commit "scsi: > ufs: issue link startup 2 times if device isn't active" leads to link lost and finally > the 3rd linkup is made again by retry mechanism in > ufshcd_link_startup() and be successful. So a linkup performance issue is > introduced here: We actually need one-time linkup only but finally got 3 linkup > operations. > > According to the UFS spec, all reset types (including POR and Host UniPro Warm > Reset which both may happen in above configurations) other than LU reset, UFS > device power mode shall return to Sleep mode or Active mode depending on > bInitPowerMode, by default, it's Active mode. As for bInitPowerMode - please see the discussion in https://www.mail-archive.com/linux-scsi@xxxxxxxxxxxxxxx/msg78262.html > > So we are curious that why enforcing twice linkup is necessary here? > Could you kindly help us clarify this?
