Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <3d5748ce4481c789000979f9831a5ae681cd9d34.camel@gmail.com>
Subject: Re: [RFC PATCH v2 3/5] scsi: ufs: Introduce HPB module
From:   Bean Huo <huobean@gmail.com>
To:     daejun7.park@samsung.com, Avri Altman <Avri.Altman@wdc.com>,
        ALIM AKHTAR <alim.akhtar@samsung.com>,
        "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
        "beanhuo@micron.com" <beanhuo@micron.com>,
        "stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
        "cang@codeaurora.org" <cang@codeaurora.org>,
        "bvanassche@acm.org" <bvanassche@acm.org>,
        "tomas.winkler@intel.com" <tomas.winkler@intel.com>
Cc:     "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Sang-yoon Oh <sangyoon.oh@samsung.com>,
        Sung-Jun Park <sungjun07.park@samsung.com>,
        yongmyung lee <ymhungry.lee@samsung.com>,
        Jinyoung CHOI <j-young.choi@samsung.com>,
        Adel Choi <adel.choi@samsung.com>,
        BoRam Shin <boram.shin@samsung.com>
Date:   Wed, 17 Jun 2020 20:24:18 +0200
In-Reply-To: <231786897.01592395081831.JavaMail.epsvc@epcpadp2>
References: <SN6PR04MB46405EC52240E00F5D634E2AFC9A0@SN6PR04MB4640.namprd04.prod.outlook.com>
         <231786897.01592212081335.JavaMail.epsvc@epcpadp2>
         <336371513.41592205783606.JavaMail.epsvc@epcpadp2>
         <231786897.01592205482200.JavaMail.epsvc@epcpadp2>
         <231786897.01592213402355.JavaMail.epsvc@epcpadp1>
         <CGME20200615062708epcms2p19a7fbc051bcd5e843c29dcd58fff4210@epcms2p5>
         <231786897.01592395081831.JavaMail.epsvc@epcpadp2>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 2020-06-17 at 19:30 +0900, Daejun Park wrote:
> > > implemented
> > > as a module parameter, so that it can be configurable by the
> > > user.
> > > 
> > > To gurantee a minimum memory pool size of 4MB:
> > > $ insmod ufshpb.ko ufshpb_host_map_kbytes=4096
> > 
> > You are going through a lot of troubles to make it a loadable
> > module.
> > What are, in your opinion, the pros and cons of this design
> > decision?
> 
> In my opinion...
> 
> pros:
> 1. A user can unload an unnecessary module when there is an
> insufficient
> memory situation (HPB case).
> 2. Since each UFS vendor has a different way of implementing UFS
> features,
> it can be supported as a separate module. Otherwise, many quirks must
> be attached to module, which is not desirable way.
> 3. It is possible to distinguish parts that are not necessary for
> essential
> ufs operation.
> 4. It is advantageous to implement the latest functions according to
> the
> development speed of UFS.
> 
> cons:
> 1. It is difficult work to be implemented as a module.
> 2. Modifying "ufsfeature.c" is required to implement the feature that
> can
> not supported by the exsiting "ufsf_operation".
> 
> Thanks,
> Daejun

Dear Avri, Daejun, Bart

It is true that it is very difficult to make everyone happy.
We now have three HPB drivers in the patchwork, but I still didn't see
a final agreement. Please tell me which one do you want to focus on?

Bean