linux-kernel - Re: [PATCH v2 1/2] scsi: ufs: Refector ufshcd_setup_clocks() to remove skip_ref

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]

Date:   Thu, 26 Nov 2020 09:45:40 +0800
From:   Can Guo <cang@...eaurora.org>
To:     Bean Huo <huobean@...il.com>
Cc:     asutoshd@...eaurora.org, nguyenb@...eaurora.org,
        hongwus@...eaurora.org, ziqichen@...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>,
        Tomas Winkler <tomas.winkler@...el.com>,
        Bean Huo <beanhuo@...ron.com>,
        Stanley Chu <stanley.chu@...iatek.com>,
        Bart Van Assche <bvanassche@....org>,
        Satya Tangirala <satyat@...gle.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] scsi: ufs: Refector ufshcd_setup_clocks() to
 remove skip_ref_clk

On 2020-11-26 03:02, Bean Huo wrote:
> On Wed, 2020-11-25 at 20:28 +0800, Can Guo wrote:
>> > On Wed, 2020-11-25 at 08:53 +0800, Can Guo wrote:
>> > > > > +       bool always_on_while_link_active;
>> > > >
>> > > > Can,
>> > > > using a sentence as a parameter name looks a little bit clumsy
>> > > > to
>> > > > me.
>> > > > The meaning has been explained in the comments section. How
>> > > > about
>> > > > simplify it and in line with other parameters in the structure?
>> > > >
>> > >
>> > > Do you have a better name in mind?
>> > >
>> >
>> > no specail input in mind, maybe just "bool eternal_on"
>> 
>> It is like plain "always_on", but it cannot tell the whole story.
>> If it is not something crutial, let's just let it go first so long
>> as it does not break the original functionality. What do you say?
>> 
>> Thanks,
>> 
>> Can Guo.
> 
> Can,
> 
> yes, it is not functional change, but always_on_while_link_active is
> too fat, and not non-productive way.
> anyway,

I will change it to keep_link_active in next version. Thank you sir.

Regards,

Can Guo.

> 
> Reviewed-by: Bean Huo <beanhuo@...ron.com>