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:   Thu, 6 Feb 2020 08:55:56 +0800
From:   Stanley Chu <stanley.chu@...iatek.com>
To:     Can Guo <cang@...eaurora.org>
CC:     <kuohong.wang@...iatek.com>, <asutoshd@...eaurora.org>,
        <nguyenb@...eaurora.org>, <hongwus@...eaurora.org>,
        <rnayak@...eaurora.org>, <linux-scsi@...r.kernel.org>,
        <kernel-team@...roid.com>, <saravanak@...gle.com>,
        <salyzyn@...gle.com>, Alim Akhtar <alim.akhtar@...sung.com>,
        Avri Altman <avri.altman@....com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Bean Huo <beanhuo@...ron.com>,
        Colin Ian King <colin.king@...onical.com>,
        Tomas Winkler <tomas.winkler@...el.com>,
        "Bart Van Assche" <bvanassche@....org>,
        Venkat Gopalakrishnan <venkatg@...eaurora.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 6/8] scsi: ufs: Add dev ref clock gating wait time
 support

Hi Can,

On Wed, 2020-02-05 at 12:52 +0800, Can Guo wrote:


> Hi Stanley,
> 
> We used to ask vendors about it, 50 is somehow agreed by them. Do you 
> have a
> better value in mind?
> 
> For me, I just wanted to give it 10, so that we can directly use 
> usleep_range
> with it, no need to decide whether to use udelay or usleep_range.

Actually I do not have any value in mind because I guess the 50us here
is just a margin time added for safety as your comments: "Give it more
time to be on the safe side".

An example case is that some vendors only specify 1us in
bRefClkGatingWaitTime, so this 50us may be too long compared to device's
requirement. If such device really needs this additional 50us, it shall
be specified in bRefClkGatingWaitTime.

So if this additional delay does not have any special reason or not
mentioned by UFS specification, would you consider move it to vendor
specific implementations. By this way, it would be more flexible to be
controlled by vendors or by platforms.

Thanks,
Stanley

> 
> Thanks,
> Can Guo.
> 
> >>  				      &dev_info->model, SD_ASCII_STD);

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ