> >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? Is it in the series that Bart referred to? Thanks, Avri
