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 v22 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>,
        Javier Gonzalez <javier.gonz@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>,
        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: <DM6PR04MB65752D7DA8F8CFAF06FFE213FC9F9@DM6PR04MB6575.namprd04.prod.outlook.com>
Message-ID: <20210225025018epcms2p5cd812ad20a9c6d4f168c4bc8a957c60f@epcms2p5>
Date:   Thu, 25 Feb 2021 11:50:18 +0900
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 102P
DLP-Filter: Pass
References: <DM6PR04MB65752D7DA8F8CFAF06FFE213FC9F9@DM6PR04MB6575.namprd04.prod.outlook.com>
        <20210222092957epcms2p728b0c563f3cfbecbf8692d7e86f9afed@epcms2p7>
        <20210222092907epcms2p307f3c4116349ebde6eed05c767287449@epcms2p3>
        <20210222093150epcms2p155352e2255e6bfd8f8d71c737ed05e76@epcms2p1>
        <CGME20210222092907epcms2p307f3c4116349ebde6eed05c767287449@epcms2p5>
Precedence: bulk

> > +       copied = ufshpb_fill_ppn_from_page(hpb, srgn->mctx, srgn_offset,
> > +                                          pre_req->wb.len - offset,
> > +                                          &addr[offset]);
> > +
> > +       if (copied < 0)
> > +               goto mctx_error;
> > +
> > +       offset += copied;
> > +       srgn_offset += offset;
> This seems wrong.
> How come the region offset is affected from the offset inside the pages?

I will change as : srgn_offset += copied
> 
> > +
> > +       if (srgn_offset == hpb->entries_per_srgn) {
> > +               srgn_offset = 0;
> > +
> > +               if (++srgn_idx == hpb->srgns_per_rgn) {
> > +                       srgn_idx = 0;
> > +                       rgn_idx++;
> > +               }
> > +       }
> > +
> > +       if (offset < pre_req->wb.len)
> > +               goto next_offset;
> If the 512k resides in a single subregion, and span across pages, fill_ppn should take care of that.
> If the 512k spans across subregion regions, than it spans across 2 subregions at most,
> and maybe you can use it.

I think it can be support span across pages.
 
The following is about the case of HPB entries are span to two page of
the mctx. fill_ppn() fills HPB entries in the first page of the mctx.
srgn_offset will be updated to check next page. In the next round,
fill_ppn() fills the entries in the second page of mctx.

Thanks,
Daejun