From: Daejun Park <daejun7.park@samsung.com>
To: Can Guo <cang@codeaurora.org>, Daejun Park <daejun7.park@samsung.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
"avri.altman@wdc.com" <avri.altman@wdc.com>,
"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>,
"huobean@gmail.com" <huobean@gmail.com>,
"bvanassche@acm.org" <bvanassche@acm.org>,
ALIM AKHTAR <alim.akhtar@samsung.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
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>,
SEUNGUK SHIN <seunguk.shin@samsung.com>
Subject: RE: Re: [PATCH v19 2/3] scsi: ufs: L2P map management for HPB read
Date: Mon, 08 Feb 2021 17:01:09 +0900 [thread overview]
Message-ID: <20210208080109epcms2p6ec657586e6afa269876d4f6205af2a3c@epcms2p6> (raw)
In-Reply-To: <652fa8013c26df497049abe923eb1b97@codeaurora.org>
> +
> > +static void ufshpb_kick_map_work(struct ufshpb_lu *hpb)
> > +{
> > + bool ret = true;
>
> -> ret = false;
>
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&hpb->rsp_list_lock, flags);
> > + if (!list_empty(&hpb->lh_inact_rgn) ||
> > !list_empty(&hpb->lh_act_srgn))
> > + ret = false;
>
> -> ret = true;
Thanks, I will fix it.
> > + spin_unlock_irqrestore(&hpb->rsp_list_lock, flags);
> > +
> > + if (ret)
> > + queue_work(ufshpb_wq, &hpb->map_work);
> > +}
> > +
> > +static bool ufshpb_is_hpb_rsp_valid(struct ufs_hba *hba,
> > + struct ufshcd_lrb *lrbp,
> > + struct utp_hpb_rsp *rsp_field)
> > +{
> > + if (be16_to_cpu(rsp_field->sense_data_len) != DEV_SENSE_SEG_LEN ||
> > + rsp_field->desc_type != DEV_DES_TYPE ||
> > + rsp_field->additional_len != DEV_ADDITIONAL_LEN ||
> > + rsp_field->hpb_op == HPB_RSP_NONE ||
>
> HPB_RSP_NONE is checked again in switch-case, no need of this line.
OK, I agree.
> > +static void ufshpb_rsp_req_region_update(struct ufshpb_lu *hpb,
> > + struct utp_hpb_rsp *rsp_field)
> > +{
> > + int i, rgn_idx, srgn_idx;
> > +
> > + BUILD_BUG_ON(sizeof(struct ufshpb_active_field) !=
> > HPB_ACT_FIELD_SIZE);
> > + /*
> > + * If the active region and the inactive region are the same,
> > + * we will inactivate this region.
> > + * The device could check this (region inactivated) and
> > + * will response the proper active region information
> > + */
> > + spin_lock(&hpb->rsp_list_lock);
> > + for (i = 0; i < rsp_field->active_rgn_cnt; i++) {
> > + rgn_idx =
> > + be16_to_cpu(rsp_field->hpb_active_field[i].active_rgn);
> > + srgn_idx =
> > + be16_to_cpu(rsp_field->hpb_active_field[i].active_srgn);
> > +
> > + dev_dbg(&hpb->sdev_ufs_lu->sdev_dev,
> > + "activate(%d) region %d - %d\n", i, rgn_idx, srgn_idx);
> > + ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
> > + hpb->stats.rb_active_cnt++;
> > + }
> > +
> > + for (i = 0; i < rsp_field->inactive_rgn_cnt; i++) {
> > + rgn_idx = be16_to_cpu(rsp_field->hpb_inactive_field[i]);
> > + dev_dbg(&hpb->sdev_ufs_lu->sdev_dev,
> > + "inactivate(%d) region %d\n", i, rgn_idx);
> > + ufshpb_update_inactive_info(hpb, rgn_idx);
> > + hpb->stats.rb_inactive_cnt++;
> > + }
> > + spin_unlock(&hpb->rsp_list_lock);
> > +
> > + dev_dbg(&hpb->sdev_ufs_lu->sdev_dev, "Noti: #ACT %u #INACT %u\n",
> > + rsp_field->active_rgn_cnt, rsp_field->inactive_rgn_cnt);
> > +
> > + queue_work(ufshpb_wq, &hpb->map_work);
> > +}
> > +
> > +/*
> > + * This function will parse recommended active subregion information
> > in sense
> > + * data field of response UPIU with SAM_STAT_GOOD state.
> > + */
> > +void ufshpb_rsp_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
> > +{
> > + struct ufshpb_lu *hpb = ufshpb_get_hpb_data(lrbp->cmd->device);
> > + struct utp_hpb_rsp *rsp_field;
> > + int data_seg_len;
> > +
> > + if (!hpb)
> > + return;
>
> You are assuming HPB recommandations only come in responses to LUs
> with HPB enabled, but the specs says the recommandations can come
> in any responses with GOOD status, meaning you should check the *hpb
> which belongs to the LUN in res_field, but not the one belongs to
> lrbp->cmd->device.
I will add codes for checking lun to prevent getting wrong HPB
recommandations.
Thanks,
Daejun
prev parent reply other threads:[~2021-02-08 8:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p6>
2021-01-29 5:28 ` [PATCH v19 0/3] scsi: ufs: Add Host Performance Booster Support Daejun Park
[not found] ` <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p3>
2021-01-29 5:30 ` [PATCH v19 2/3] scsi: ufs: L2P map management for HPB read Daejun Park
2021-02-05 11:15 ` Bean Huo
2021-02-05 11:42 ` Avri Altman
2021-02-05 11:54 ` Bean Huo
[not found] ` <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p2>
2021-02-08 8:00 ` Daejun Park
2021-02-06 7:23 ` Can Guo
2021-02-06 9:14 ` Bean Huo
2021-02-06 19:17 ` Avri Altman
2021-02-08 7:21 ` Can Guo
[not found] ` <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p5>
2021-01-29 5:30 ` [PATCH v19 3/3] scsi: ufs: Prepare HPB read for cached sub-region Daejun Park
2021-02-05 3:29 ` Can Guo
2021-02-05 12:35 ` Bean Huo
2021-02-05 14:06 ` Avri Altman
2021-02-05 15:08 ` Bean Huo
2021-02-07 7:36 ` Can Guo
2021-02-07 10:44 ` Bean Huo
2021-02-09 13:25 ` Avri Altman
2021-02-09 14:21 ` Bean Huo
2021-02-10 5:32 ` Can Guo
2021-02-08 8:16 ` Bean Huo
2021-02-08 9:58 ` Can Guo
2021-02-10 9:36 ` Avri Altman
2021-02-08 8:03 ` Re: [PATCH v19 2/3] scsi: ufs: L2P map management for HPB read Daejun Park
2021-02-08 8:34 ` Can Guo
[not found] ` <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p1>
2021-01-29 5:29 ` [PATCH v19 1/3] scsi: ufs: Introduce HPB feature Daejun Park
2021-02-02 7:46 ` Avri Altman
2021-02-02 11:12 ` Greg KH
2021-02-08 8:53 ` Re: [PATCH v19 2/3] scsi: ufs: L2P map management for HPB read Daejun Park
2021-02-08 9:23 ` Can Guo
[not found] ` <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p8>
2021-02-09 1:27 ` Daejun Park
2021-02-09 2:28 ` Can Guo
2021-02-08 8:01 ` Daejun Park [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210208080109epcms2p6ec657586e6afa269876d4f6205af2a3c@epcms2p6 \
--to=daejun7.park@samsung.com \
--cc=alim.akhtar@samsung.com \
--cc=asutoshd@codeaurora.org \
--cc=avri.altman@wdc.com \
--cc=boram.shin@samsung.com \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=huobean@gmail.com \
--cc=j-young.choi@samsung.com \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=seunguk.shin@samsung.com \
--cc=stanley.chu@mediatek.com \
--cc=sungjun07.park@samsung.com \
--cc=ymhungry.lee@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).