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] [day] [month] [year] [list]

Message-ID: <1579247852.19362.10.camel@mtksdccf07>
Date:   Fri, 17 Jan 2020 15:57:32 +0800
From:   Stanley Chu <stanley.chu@...iatek.com>
To:     Can Guo <cang@...eaurora.org>
CC:     "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "bvanassche@....org" <bvanassche@....org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        Peter Wang (王信友) 
        <peter.wang@...iatek.com>,
        "CC Chou (周志杰)" 
        <cc.chou@...iatek.com>,
        "Andy Teng ( .$B{}G!9(.(B)" 
        <Andy.Teng@...iatek.com>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        Chun-Hung Wu (巫駿宏) 
        <Chun-hung.Wu@...iatek.com>,
        Ron Hsu (許軒榮) 
        <Ron.Hsu@...iatek.com>,
        "avri.altman@....com" <avri.altman@....com>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "linux-scsi-owner@...r.kernel.org" <linux-scsi-owner@...r.kernel.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        Kuohong Wang (王國鴻) 
        <kuohong.wang@...iatek.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "subhashj@...eaurora.org" <subhashj@...eaurora.org>,
        "pedrom.sousa@...opsys.com" <pedrom.sousa@...opsys.com>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>
Subject: Re: [PATCH v1 1/2] scsi: ufs: set device as default active power
 mode during initialization only

Hi Can,

On Fri, 2020-01-03 at 13:28 +0800, Can Guo wrote:
> > 
> > Hi Stanley,
> > 
> > Above description is correct. The reason why the UFS device becomes
> > Active after the 1st link startup in your experiment is due to you
> > set spm_lvl to 5, during system suspend, UFS device is powered down.
> > When resume kicks start, the UFS device is power cycled once.
> > 
> > Moreover, if you set rpm_lvl to 5, during runtime suspend, if bkops is
> > enabled, the UFS device will not be powered off, meaning when runtime
> > resume kicks start, the UFS device is not power cycled, in this case,
> > we need 3 times of link startup.
> > 
> > Does above explain?
> > 
> > Thanks,
> > 
> > Can Guo.
> > 
> 
> Hi Stanley,
> 
> Sorry, typo before. I meant if set rpm_lvl/spm_lvl to 5, during suspend,
> if is_lu_power_on_wp is set, the UFS device will not be fully powered 
> off
> (only VCC is down), meaning when resume kicks start, the UFS device is 
> not
> power cycled, in this case, we need 3 times of link startup.
> 
> Regards,
> 
> Can Guo.

Hi Can,

Very sorry for late responding this thread.

Now I would like to focus on 3-times link startup behavior found in our
platform because this dramatically downgrade resume performance.

According to your description, then could the driver set
"link_startup_again" as true only if "is_lu_power_on_wp" is set to avoid
unnecessary three-times link startup in other cases?

In addition, for the scenario you mentioned: "the UFS device will not be
fully powered off (only VCC is down), meaning when resume kicks start,
the UFS device is not power cycled": 

1. Actually I tried to set xpm_lvl=5, and enforced "is_lu_power_on_wp"
as true for evaluation, but found device can be still back to Active
PowerMode (can be accessed normally) after one-time link startup after
resumed. 

Only VCC is down and VCCQ2 is kept during suspend in my evaluation.

2. In this scenario, during resume the peer device shall have "UniPro
Warm Reset" triggered by the first link start-up and then device power
mode shall become Active according to UFS specification.

So what device power mode did you see after the first link startup in
this scenario? Or any other conditions to make device need
"link_startup_again"?

Thanks,
Stanley