Messages in this thread | | | Date | Mon, 28 Jun 2021 15:16:52 +0800 | From | Can Guo <> | Subject | Re: [PATCH v4 10/10] scsi: ufs: Apply more limitations to user access |
| |
On 2021-06-25 06:25, Bart Van Assche wrote: > On 6/23/21 7:23 PM, Can Guo wrote: >> On 2021-06-24 05:51, Bart Van Assche wrote: >>> On 6/23/21 12:35 AM, Can Guo wrote: >>> - During system suspend, user space software is paused before the >>> device >>> driver freeze callbacks are invoked. Hence, the >>> hba->is_sys_suspended >>> check can be left out. >> >> is_sys_suspended indicates that system resume failed (power/clk is >> OFF). >> >>> - If a LUN is runtime suspended, it should be resumed if accessed >>> from >>> user space instead of failing user space accesses. In other words, >>> the >>> hba->is_wlu_sys_suspended check seems inappropriate to me. >> >> hba->is_wlu_sys_suspended indicates that wl system resume failed, >> device >> is not operational. > > Hi Can, > > Thanks for the clarification. How about converting the above two > answers > into comments inside ufshcd_is_user_access_allowed()? >
Sure.
> Should ufshcd_is_user_access_allowed() perhaps be called after > ufshcd_rpm_get_sync() instead of before to prevent that the value of > hba->is_sys_suspended or hba->is_wlu_sys_suspended changes after having > been checked and before the UFS device is accessed? >
is_sys_suspended and is_wlu_sys_suspended only represent system PM status, not runtime PM status.
My understanding is that user threads are frozen before system PM starts, so it does not matter we call ufshcd_is_user_access_allowed() before or after ufshcd_rpm_get_sync().
If my understanding is wrong, then we need to either call lock_system_sleep() in get_user_access() or wrap ufshcd_suspend_prepare/ufshcd_resume_complete() with host_sem.
Thanks,
Can Guo.
> Thanks, > > Bart.
| |