linux-kernel - RE: [PATCH 2/3] scsi: ufs: Keep device power on only fWriteBoosterBufferFlushDuringHibernate == 1

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]

Message-ID: <DM6PR04MB657551290696C7EBD8339328FCF20@DM6PR04MB6575.namprd04.prod.outlook.com>
Date:   Thu, 3 Dec 2020 10:46:02 +0000
From:   Avri Altman <Avri.Altman@....com>
To:     Bean Huo <huobean@...il.com>,
        "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "stanley.chu@...iatek.com" <stanley.chu@...iatek.com>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "bvanassche@....org" <bvanassche@....org>,
        "tomas.winkler@...el.com" <tomas.winkler@...el.com>,
        "cang@...eaurora.org" <cang@...eaurora.org>
CC:     "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/3] scsi: ufs: Keep device power on only
 fWriteBoosterBufferFlushDuringHibernate == 1

> 
> On Thu, 2020-12-03 at 07:27 +0000, Avri Altman wrote:
> > >
> > > From: Bean Huo <beanhuo@...ron.com>
> > >
> > > Keep device power mode as active power mode and VCC supply only if
> > > fWriteBoosterBufferFlushDuringHibernate setting 1 is successful.
> 
> Hi Avri
> Thanks so much taking time reiew.
> 
> > Why would it fail?
> 
> During the reliability testing in harsh environments, such as:
> EMS testing, in the high/low-temperature environment. The system would
> reboot itself, there will be programming failure very likely.
> If we assume failure will never hit, why we capture its result
> following with dev_err(). If you keep using your phone in a harsh
> environment, you will see this print message.
> 
> Of course, in a normal environment, the chance of failure likes you to
> win a lottery, but the possibility still exists.
Exactly.
Hence we need-not any extra logic protecting device management command failures.

if reading the configuration pass correctly, and UFSHCD_CAP_WB_EN is set,
one should expect that any other functionality would work.

Otherwise, any non-standard behavior should be added with a quirk.

Thanks,
Avri
> 
> 
> > Since UFSHCD_CAP_WB_EN is toggled off on ufshcd_wb_probe If the
> > device doesn't support wb,
> > The check ufshcd_is_wb_allowed should suffice, isn't it?
> >
> 
> No, UFSHCD_CAP_WB_EN only tells us if the platform supports WB,
> doesn't tell us fWriteBoosterBufferFlushDuringHibernate status.
> 
> Thanks,
> Bean
>