On Sat, Feb 06 2021 at 11:24 -0800, Avri Altman wrote:
>Regardless of your above proposal, as for the issues you were witnessing with
rpmb,
>That started this RFC in the first place, and the whole clearing uac series for
that matter:
> "In order to conduct FFU or RPMB operations, UFS needs to clear UNIT
ATTENTION condition...."
>
>Functionally, This was already done for the device wlun, and only added the
rpmb wlun.
>
>Now you are trying to solve stuff because the rpmb is not provisioned.
>a) There should be no relation between response to request-sense command,
> and if the key is programmed or not. And
>b) rpmb is accessed from user-space. If it is not provisioned, it should
processed the error (-7)
> and realize that by itself. And also, It only makes sense that if needed,
> the access sequence will include the request-sense command.
>
>Therefore, IMHO, just reverting Randall commit (1918651f2d7e) and fixing
the user-space code
>Should suffice.
>
>Thanks,
>Avri
>
Hi Avri
Thanks.
I don't think reverting 1918651f2d7e would fix this.
[ 12.182750] ufshcd-qcom 1d84000.ufshc: ufshcd_suspend: Setting power
mode
[ 12.190467] ufshcd-qcom 1d84000.ufshc: wlun_dev_clr_ua: 0 <-- uac wasn't
sent
[ 12.196735] ufshcd-qcom 1d84000.ufshc: Sending ssu
[ 12.202412] scsi 0:0:0:49488: Queue rpm status b4 ssu: 2 <- sdev_ufs_device
queue is suspended
[ 12.208613] ufshcd-qcom 1d84000.ufshc: Wait for resume - <-- deadlock!
The issue is sending any command to any lun which is registered for blk
runtime-pm in ufs host's suspend path would deadlock; since, it'd try to resume
the ufs host in the same suspend calling sequence.
Did you managed to bisect the commit that caused the regression?
No - I didn't bisect.
Is it in the series that Bart referred to?
Yes - the debug points to that.
Thanks,
Avri
