linux-kernel - RE: [PATCH v1 1/2] scsi: ufs: set device as default active power mode during initialization only

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 5 Jan 2020 07:55:25 +0000
From:   Avri Altman <Avri.Altman@....com>
To:     Stanley Chu <stanley.chu@...iatek.com>,
        Can Guo <cang@...eaurora.org>
CC:     "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "andy.teng@...iatek.com" <andy.teng@...iatek.com>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "chun-hung.wu@...iatek.com" <chun-hung.wu@...iatek.com>,
        "kuohong.wang@...iatek.com" <kuohong.wang@...iatek.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "peter.wang@...iatek.com" <peter.wang@...iatek.com>,
        "linux-scsi-owner@...r.kernel.org" <linux-scsi-owner@...r.kernel.org>,
        "subhashj@...eaurora.org" <subhashj@...eaurora.org>,
        "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "pedrom.sousa@...opsys.com" <pedrom.sousa@...opsys.com>,
        "bvanassche@....org" <bvanassche@....org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "ron.hsu@...iatek.com" <ron.hsu@...iatek.com>,
        "cc.chou@...iatek.com" <cc.chou@...iatek.com>
Subject: RE: [PATCH v1 1/2] scsi: ufs: set device as default active power mode
 during initialization only

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@vger.kernel.org/msg78262.html



> 
> So we are curious that why enforcing twice linkup is necessary here?
> Could you kindly help us clarify this?