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;
Mime-Version: 1.0
Subject: RE: RE: [PATCH v24 4/4] scsi: ufs: Add HPB 2.0 support
Reply-To: daejun7.park@samsung.com
Sender: Daejun Park <daejun7.park@samsung.com>
From:   Daejun Park <daejun7.park@samsung.com>
To:     Avri Altman <Avri.Altman@wdc.com>,
        Daejun Park <daejun7.park@samsung.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
        "stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
        "cang@codeaurora.org" <cang@codeaurora.org>,
        "bvanassche@acm.org" <bvanassche@acm.org>,
        "huobean@gmail.com" <huobean@gmail.com>,
        ALIM AKHTAR <alim.akhtar@samsung.com>
CC:     "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        JinHwan Park <jh.i.park@samsung.com>,
        Javier Gonzalez <javier.gonz@samsung.com>,
        SEUNGUK SHIN <seunguk.shin@samsung.com>,
        Sung-Jun Park <sungjun07.park@samsung.com>,
        yongmyung lee <ymhungry.lee@samsung.com>,
        Jinyoung CHOI <j-young.choi@samsung.com>,
        BoRam Shin <boram.shin@samsung.com>
In-Reply-To: <DM6PR04MB6575ECC05596740425EC948EFC9F9@DM6PR04MB6575.namprd04.prod.outlook.com>
Message-ID: <20210225032534epcms2p5cf03d488df6c16923eb1ddfaa50c1266@epcms2p5>
Date:   Thu, 25 Feb 2021 12:25:34 +0900
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 102P
DLP-Filter: Pass
References: <DM6PR04MB6575ECC05596740425EC948EFC9F9@DM6PR04MB6575.namprd04.prod.outlook.com>
        <20210224045323epcms2p66cc6a4b73086621e050da37f12f432f0@epcms2p6>
        <20210224045532epcms2p2215025506b062e2fdbad73e51563dca6@epcms2p2>
        <DM6PR04MB65759C2968CDEFF32A0A95FDFC9F9@DM6PR04MB6575.namprd04.prod.outlook.com>
        <CGME20210224045323epcms2p66cc6a4b73086621e050da37f12f432f0@epcms2p5>
Precedence: bulk

> > 
> > > +static int ufshpb_issue_umap_all_req(struct ufshpb_lu *hpb)
> > Maybe ufshpb_issue_umap_all_req is just a wrapper for
> > ufshpb_issue_umap_req?
> > e.g it calls ufshpb_issue_umap_req(hpb, int read_buferr_id = 0x3) ?
> > Then on host mode inactivation:
> > static int ufshpb_issue_umap_single_req(struct ufshpb_lu *hpb)
> > {
> >         return ufshpb_issue_umap_req(hpb, 0x1);
> > }
> Better yet, ufshpb_execute_umap_req can get *rgn as an extra argument.
> ufshpb_issue_umap_all_req will call it with NULL, while
> ufshpb_issue_umap_single_req will call it with the rgn to inactivate.
> 
> Then,  ufshpb_set_unmap_cmd takes the form:
> static void ufshpb_set_unmap_cmd(unsigned char *cdb, struct ufshpb_region *rgn)
> {
>         cdb[0] = UFSHPB_WRITE_BUFFER;
> 
>         if (rgn) {
>                 cdb[1] = UFSHPB_WRITE_BUFFER_INACT_SINGLE_ID;
>                 put_unaligned_be16(rgn->rgn_idx, &cdb[2]);
>         } else {
>                 cdb[1] = UFSHPB_WRITE_BUFFER_INACT_ALL_ID;
>         }
> 
>         cdb[9] = 0x00;
> }
> 
> Does it make sense?

I got it.

Thanks,
Daejun