| 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
| ||
|
Message-ID: <1589423030.3197.94.camel@mtkswgap22>
Date: Thu, 14 May 2020 10:23:50 +0800
From: Stanley Chu <stanley.chu@...iatek.com>
To: "Asutosh Das (asd)" <asutoshd@...eaurora.org>
CC: <linux-scsi@...r.kernel.org>, <martin.petersen@...cle.com>,
<avri.altman@....com>, <alim.akhtar@...sung.com>,
<jejb@...ux.ibm.com>, <beanhuo@...ron.com>, <cang@...eaurora.org>,
<matthias.bgg@...il.com>, <bvanassche@....org>,
<linux-mediatek@...ts.infradead.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <kuohong.wang@...iatek.com>,
<peter.wang@...iatek.com>, <chun-hung.wu@...iatek.com>,
<andy.teng@...iatek.com>
Subject: Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime
suspend
Hi Asutosh,
On Wed, 2020-05-13 at 12:31 -0700, Asutosh Das (asd) wrote:
> On 5/12/2020 3:47 AM, Stanley Chu wrote:
> > Currently UFS host driver promises VCC supply if UFS device
> > needs to do WriteBooster flush during runtime suspend.
> >
> > However the UFS specification mentions,
> >
> > "While the flushing operation is in progress, the device is
> > in Active power mode."
> >
> > Therefore UFS host driver needs to promise more: Keep UFS
> > device as "Active power mode", otherwise UFS device shall not
> > do any flush if device enters Sleep or PowerDown power mode.
> >
> > Fix this by not changing device power mode if WriteBooster
> > flush is required in ufshcd_suspend().
> >
> > Signed-off-by: Stanley Chu <stanley.chu@...iatek.com>
> > ---
> > drivers/scsi/ufs/ufs.h | 1 -
> > drivers/scsi/ufs/ufshcd.c | 39 +++++++++++++++++++--------------------
> > 2 files changed, 19 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> > index b3135344ab3f..9e4bc2e97ada 100644
> > --- a/drivers/scsi/ufs/ufs.h
> > +++ b/drivers/scsi/ufs/ufs.h
> > @@ -577,7 +577,6 @@ struct ufs_dev_info {
> > u32 d_ext_ufs_feature_sup;
> > u8 b_wb_buffer_type;
> > u32 d_wb_alloc_units;
> > - bool keep_vcc_on;
> > u8 b_presrv_uspc_en;
> > };
> >
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index 169a3379e468..2d0aff8ac260 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba)
> > !hba->dev_info.is_lu_power_on_wp) {
> > ufshcd_setup_vreg(hba, false);
> > } else if (!ufshcd_is_ufs_dev_active(hba)) {
> > - if (!hba->dev_info.keep_vcc_on)
> > - ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
> > + ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
> > if (!ufshcd_is_link_active(hba)) {
> > ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq);
> > ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2);
> > @@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
> > enum ufs_pm_level pm_lvl;
> > enum ufs_dev_pwr_mode req_dev_pwr_mode;
> > enum uic_link_state req_link_state;
> > + bool keep_curr_dev_pwr_mode = false;
> >
> > hba->pm_op_in_progress = 1;
> > if (!ufshcd_is_shutdown_pm(pm_op)) {
> > @@ -8226,28 +8226,27 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
> > /* make sure that auto bkops is disabled */
> > ufshcd_disable_auto_bkops(hba);
> > }
> > +
> Unnecessary newline, perhaps?
Yap, I will remove it in next version.
> > /*
> > - * With wb enabled, if the bkops is enabled or if the
> > - * configured WB type is 70% full, keep vcc ON
> > - * for the device to flush the wb buffer
> > + * If device needs to do BKOP or WB buffer flush, keep device
> > + * power mode as "active power mode" and its VCC supply.
> > */
> > - if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) ||
> > - ufshcd_wb_keep_vcc_on(hba))
> > - hba->dev_info.keep_vcc_on = true;
> > - else
> > - hba->dev_info.keep_vcc_on = false;
> > - } else {
> > - hba->dev_info.keep_vcc_on = false;
> > + keep_curr_dev_pwr_mode = hba->auto_bkops_enabled ||
> > + ufshcd_wb_keep_vcc_on(hba);
> Should the device be in UFS_ACTIVE_PWR_MODE to perform auto-bkops?
>
> Also, is it needed to keep the device in UFS_ACTIVE_PWR_MODE , if flush
> on hibern8 is enabled and the link is being put to hibern8 mode during
> runtime-suspend? Perhaps that should also be factored in here?
Both auto-bkops and WriteBooster flush during Hibern8 need device power
mode to be "Active Power Mode".
For auto-bkops, the spec mentions,
"If the background operations enable bit is set and the device is in
Active power mode or Idle power mode, then the device is allowed to
execute any internal operations."
For WriteBooster flush during Hibern8, the spec mentions,
"While the flushing operation is in progress, the device is in Active
power mode."
Therefore here we can use an unified "keep_curr_dev_pwr_mode" to
indicate the same requirements of above both features.
Besides, both operations may access flash array inside UFS device thus
VCC supply shall be also kept.
Before this patch, the original code will keep device power mode (stay
in Active Power Mode) if hba->auto_bkops_enabled is set as true during
runtime-suspend with UFSHCD_CAP_AUTO_BKOPS_SUSPEND capability is
enabled. This patch will not change this decision, just add
"WriteBooster flush during Hibern8" feature as another condition to do
so.
Thank you so much to remind me that "Link shall be put in Hibern8" is a
necessary condition for "WriteBooster flush during Hibern8". I will add
more checking for keep_curr_dev_pwr_mode to prevent unnecessary power
drain.
> > }
> >
> > - if ((req_dev_pwr_mode != hba->curr_dev_pwr_mode) &&
> > - ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
> > - !ufshcd_is_runtime_pm(pm_op))) {
> > - /* ensure that bkops is disabled */
> > - ufshcd_disable_auto_bkops(hba);
> > - ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
> > - if (ret)
> > - goto enable_gating;
> > + if (req_dev_pwr_mode != hba->curr_dev_pwr_mode) {
> > + if ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
> > + !ufshcd_is_runtime_pm(pm_op)) {
> > + /* ensure that bkops is disabled */
> > + ufshcd_disable_auto_bkops(hba);
> > + }
> > +
> > + if (!keep_curr_dev_pwr_mode) {
> > + ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
>
> Now, when the WB buffer is completely flushed out, the device should be
> put back into UFS_SLEEP_PWR_MODE or UFS_POWERDOWN_PWR_MODE. Say, the
> device buffer has to be flushed and during runtime-suspend, the device
> is put to UFS_ACTIVE_PWR_MODE and Vcc is kept ON; the device doesn't
> resume nor does the system enters suspend for a very long time, and with
> AH8 and hibern8 disabled, there will be an unnecessary power drain for
> that much time.
>
> How about a periodic interval checking of flush status if
> keep_curr_dev_pwr_mode evaluates to be true?
This is a good point!
The same thing also happens for auto-bkops. How about add a timer to
leave runtime suspend if keep_curr_dev_pwr_mode is set as true? This is
simple and also favors power. The timeout value could be adjustable
according to the available WriteBooster buffer size.
A periodic interval checking of flush status needs to re-activate link
to communicate with the device. This would be tricky and the
re-activation flow is just like runtime-resume.
What would you think?
Thanks.
Stanley Chu
Powered by blists - more mailing lists