linux-kernel - RE: [EXT] Re: [PATCH v3 4/8] scsi: ufs: move ufshcd_get_max_pwr_mode() to ufs_init

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: <BN7PR08MB5684F3522EFC24CFAE250C35DB330@BN7PR08MB5684.namprd08.prod.outlook.com>
Date:   Sun, 19 Jan 2020 22:21:22 +0000
From:   "Bean Huo (beanhuo)" <beanhuo@...ron.com>
To:     Alim Akhtar <alim.akhtar@...il.com>, Bean Huo <huobean@...il.com>
CC:     Alim Akhtar <alim.akhtar@...sung.com>,
        Avri Altman <avri.altman@....com>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Stanley Chu <stanley.chu@...iatek.com>,
        Bart Van Assche <bvanassche@....org>,
        Tomas Winkler <tomas.winkler@...el.com>,
        Can Guo <cang@...eaurora.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: RE: [EXT] Re: [PATCH v3 4/8] scsi: ufs: move
 ufshcd_get_max_pwr_mode() to ufs_init_params()

Hi, Alim

> > From: Bean Huo <beanhuo@...ron.com>
> >
> > ufshcd_get_max_pwr_mode() only need to be called once while booting,
> > take it out from ufshcd_probe_hba() and inline into ufshcd_init_params().
> >
> This can be safely squash with the previous patch which introduce
> ufshcd_init_params.
>

I kept this patch because I want you to review the patch easily. The previous patch is exactly to
split ufshcd_probe_hba(), doesn't want to do any initialization path flow changing. If I merge this
patch to the previous one, that will disorder the original calling process, and some reviewers will
have more concern about previous patch.

kept them independently, for the previous patch, you only need to check its split-up validity.


Thanks,

//Bean