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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9484cba7b95c6c6fcbafd96bc35c1dee@codeaurora.org>
Date:   Wed, 25 Nov 2020 20:28:15 +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-25 19:54, Bean Huo 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.

> 
>> Thanks,
>> 
>> Can Guo.