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:   Tue, 31 Dec 2019 16:05:59 +0800
From:   Can Guo <cang@...eaurora.org>
To:     Stanley Chu <stanley.chu@...iatek.com>
Cc:     linux-scsi-owner@...r.kernel.org, linux-scsi@...r.kernel.org,
        martin.petersen@...cle.com, subhashj@...eaurora.org,
        jejb@...ux.ibm.com, chun-hung.wu@...iatek.com,
        kuohong.wang@...iatek.com, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, avri.altman@....com,
        linux-mediatek@...ts.infradead.org, peter.wang@...iatek.com,
        alim.akhtar@...sung.com, andy.teng@...iatek.com,
        matthias.bgg@...il.com, beanhuo@...ron.com,
        pedrom.sousa@...opsys.com, bvanassche@....org,
        linux-arm-kernel@...ts.infradead.org, asutoshd@...eaurora.org
Subject: Re: [PATCH v1 1/2] scsi: ufs: set device as default active power mode
 during initialization only

On 2019-12-31 12:22, Stanley Chu wrote:
> Hi Can,
> 
> 
>> Hi Stanley,
>> 
>> I see skipping ufshcd_set_ufs_dev_active() in ufshcd_probe_hba()
>> if it is called from ufshcd_resume() path is the purpose here.
>> 
>> If so, then ufshcd_set_dev_pwr_mode() would be called, meaning
>> SSU command will be sent. Why is this SSU command needed to be
>> sent after a full host reset and restore? Is ufshcd_probe_hba()
>> not enough to make UFS device fully functional?
> 
> After resume (for both runtime resume and system resume), device power
> mode shall be back to "Active" to service incoming requests.
> 
> I see two cases need device power mode transition during resume flow
> 1. Device Power Mode = Sleep
> 2. Device Power Mode = PowerDown
> 
> For 1, ufshcd_probe_hba() is not invoked during resume flow,
> hba->curr_dev_pwr_mode = SLEEP, thus ufshcd_resume() can invoke
> ufshcd_set_dev_pwr_mode() to change device power mode.
> 
> For 2, ufshcd_probe_hba() is invoked during resume flow, before this
> fix, hba->curr_dev_pwr_mode will be set to ACTIVE (note that only this
> flag is set as ACTIVE, but device may be still in PowerDown state if
> device power is not fully shutdown or device HW reset is not executed
> before resume), in the end, ufshcd_resume() will not invoke
> ufshcd_set_dev_pwr_mode() to send SSU command to make device change 
> back
> to Active power mode.

Hi Stanley,

Isn't below change fixing the problem you are saying above?
With it, after ufshcd_link_startup(), UFS device's power mode will
become Active anyways. Do you mean below change is not working properly
and you are removing it?

commit 7caf489b99a42a9017ef3d733912aea8794677e7
Author: subhashj@...eaurora.org <subhashj@...eaurora.org>
Date:   Wed Nov 23 16:32:20 2016 -0800

     scsi: ufs: issue link starup 2 times if device isn't active

     If we issue the link startup to the device while its UniPro state is
     LinkDown (and device state is sleep/power-down) then link startup
     will not move the device state to Active. Device will only move to
     active state if the link starup is issued when its UniPro state is
     LinkUp. So in this case, we would have to issue the link startup 2
     times to make sure that device moves to active state.

Thanks,

Can Guo

> 
> But if device is fully reset before resume (not by current mainstream
> driver), device can be already in "Active" power mode after power on
> again during resume flow. In this case, it is OK to set
> hba->curr_dev_pwr_mode as ACTIVE in ufshcd_probe_hba() and SSU command
> is not necessary.
> 
> Thanks,
> Stanley
> 
>> _______________________________________________
>> Linux-mediatek mailing list
>> Linux-mediatek@...ts.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ