linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daejun Park <daejun7.park@samsung.com>
To: Bart Van Assche <bvanassche@acm.org>,
	Daejun Park <daejun7.park@samsung.com>,
	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>,
	"cang@codeaurora.org" <cang@codeaurora.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>,
	Sung-Jun Park <sungjun07.park@samsung.com>,
	Jinyoung CHOI <j-young.choi@samsung.com>,
	Dukhyun Kwon <d_hyun.kwon@samsung.com>,
	Keoseong Park <keosung.park@samsung.com>,
	Jaemyung Lee <jaemyung.lee@samsung.com>,
	Jieon Seol <jieon.seol@samsung.com>
Subject: RE: Re: [PATCH v36 4/4] scsi: ufs: Add HPB 2.0 support
Date: Thu, 10 Jun 2021 15:23:54 +0900	[thread overview]
Message-ID: <20210610062354epcms2p19ed22ed39a4e2fce53dafb8e51b1364f@epcms2p1> (raw)
In-Reply-To: <25912c0a-7f52-8b04-2ac1-6686aee01f87@acm.org>

Hi Bart,

>On 6/6/21 9:19 PM, Daejun Park wrote:
>> -What:                /sys/class/scsi_device/*/device/hpb_sysfs/hit_cnt
>> +What:                /sys/class/scsi_device/*/device/hpb_stat_sysfs/hit_cnt
>>  Date:                June 2021
>>  Contact:        Daejun Park <daejun7.park@samsung.com>
>>  Description:        This entry shows the number of reads that changed to HPB read.
>>  
>>                  The file is read only.
> 
>Is it really useful to have a suffix "_sysfs" for a directory that
>occurs in sysfs? If not, please leave it out.
> 
>Should "hpb_stat" perhaps be renamed into "hpb_stats"? An example of
>another directory with statistics is /sys/power/suspend_stats. The name
>of that directory also ends in "stats" (plural form).

OK, I will change it.

> 
>> +What:                /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_size_hpb_single_cmd
>> +Date:                June 2021
>> +Contact:        Daejun Park <daejun7.park@samsung.com>
>> +Description:        This entry shows the maximum HPB data size for using single HPB
>> +                command.
>> +
>> +                ===  ========
>> +                00h  4KB
>> +                01h  8KB
>> +                02h  12KB
>> +                ...
>> +                FFh  1024KB
>> +                ===  ========
>> +
>> +                The file is read only.
> 
>This is not clear enough. What are the values reported through this
>sysfs attribute? Are that perhaps the values 00h .. FFh? Is the software
>that reads this attribute perhaps expected to convert this attribute
>from hex to int and next convert the int into a size in KB by using the
>above lookup table? That seems awkward to me. Please report the maximum
>data size directly, either in KB or in bytes.

We show the bMAX_DATA_SIZE_FOR_SINGLE_CMD value just like other existing
ufs sysfs attributes. In the case of sysfs for the bRefClkFreq value, it
shows the raw value read from the device, not the value converted to HZ.

>> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
>> index f99059b31e0a..d902414e4a6f 100644
>> --- a/drivers/scsi/ufs/ufshcd.h
>> +++ b/drivers/scsi/ufs/ufshcd.h
>> @@ -652,6 +652,8 @@ struct ufs_hba_variant_params {
>>   * @srgn_size: device reported HPB sub-region size
>>   * @slave_conf_cnt: counter to check all lu finished initialization
>>   * @hpb_disabled: flag to check if HPB is disabled
>> + * @max_hpb_single_cmd: maximum size of single HPB command
>> + * @is_legacy: flag to check HPB 1.0
>>   */
>>  struct ufshpb_dev_info {
>>          int num_lu;
>> @@ -659,6 +661,8 @@ struct ufshpb_dev_info {
>>          int srgn_size;
>>          atomic_t slave_conf_cnt;
>>          bool hpb_disabled;
>> +        int max_hpb_single_cmd;
>> +        bool is_legacy;
>>  };
>>  #endif
> 
>Elsewhere in this patch I see that max_hpb_single_cmd is the value read
>from the bMAX_DATA_SIZE_FOR_SINGLE_CMD descriptor (one byte). Does this
>mean that the type of 'max_hpb_single_cmd' should be changed into
>uint8_t? Additionally, please make it clear in the comment block above
>struct ufshpb_dev_info that max_hpb_single_cmd is not a size in bytes.

OK, it will be u8 and the comments will be as follows.
@max_hpb_single_cmd: the value of bMAX_DATA_SIZE_FOR_SINGLE_CMD.

> 
>> +bool ufshpb_is_legacy(struct ufs_hba *hba)
>> +{
>> +        return hba->ufshpb_dev.is_legacy;
>> +}
> 
>Please add a comment above this function that explains what 'legacy'
>means in the context of HPB.

OK, I will add:
/* HPB version 1.0 is called as legacy version. */

> 
>> +static int ufshpb_execute_umap_req(struct ufshpb_lu *hpb,
>> +                                   struct ufshpb_req *umap_req,
>> +                                   struct ufshpb_region *rgn)
>> +{
>> +        struct request *req;
>> +        struct scsi_request *rq;
>> +
>> +        req = umap_req->req;
>> +        req->timeout = 0;
>> +        req->end_io_data = (void *)umap_req;
>> +        rq = scsi_req(req);
>> +        ufshpb_set_unmap_cmd(rq->cmd, rgn);
>> +        rq->cmd_len = HPB_WRITE_BUFFER_CMD_LENGTH;
>> +
>> +        blk_execute_rq_nowait(NULL, req, 1, ufshpb_umap_req_compl_fn);
>> +
>> +        return 0;
>> +}
> 
>This function always returns 0. Please change the return type from 'int'
>into 'void'.

Sure.

> 
>> +/* SYSFS functions */
>> +#define ufshpb_sysfs_param_show_func(__name)                                \
>> +static ssize_t __name##_show(struct device *dev,                        \
>> +        struct device_attribute *attr, char *buf)                        \
>> +{                                                                        \
>> +        struct scsi_device *sdev = to_scsi_device(dev);                        \
>> +        struct ufshpb_lu *hpb = ufshpb_get_hpb_data(sdev);                \
>> +        if (!hpb)                                                        \
>> +                return -ENODEV;                                                \
>> +                                                                        \
>> +        return sysfs_emit(buf, "%d\n", hpb->params.__name);                \
>> +}
> 
>Please leave a blank line between variable declarations and code.

OK, I will add it.

Thanks,
Daejun

>Thanks,
> 
>Bart.
> 
> 
>  

  parent reply	other threads:[~2021-06-10  6:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210607041650epcms2p29002c9d072738bbf21fb4acf31847e8e@epcms2p2>
2021-06-07  4:16 ` [PATCH v36 0/4] scsi: ufs: Add Host Performance Booster Support Daejun Park
     [not found]   ` <CGME20210607041650epcms2p29002c9d072738bbf21fb4acf31847e8e@epcms2p5>
2021-06-07  4:18     ` [PATCH v36 3/4] scsi: ufs: Prepare HPB read for cached sub-region Daejun Park
     [not found]   ` <CGME20210607041650epcms2p29002c9d072738bbf21fb4acf31847e8e@epcms2p7>
2021-06-07  4:19     ` [PATCH v36 4/4] scsi: ufs: Add HPB 2.0 support Daejun Park
2021-06-10  1:55       ` 정요한(JOUNG YOHAN) Mobile SE
2021-06-10  3:37       ` Bart Van Assche
2021-06-10  6:07         ` Greg KH
     [not found]       ` <CGME20210607041650epcms2p29002c9d072738bbf21fb4acf31847e8e@epcms2p1>
2021-06-10  6:23         ` Daejun Park [this message]
2021-06-09  9:53   ` [PATCH v36 0/4] scsi: ufs: Add Host Performance Booster Support Greg KH
2021-06-07  4:17 ` [PATCH v36 1/4] scsi: ufs: Introduce HPB feature Daejun Park
2021-06-10 16:45   ` Bart Van Assche
     [not found]   ` <CGME20210607041650epcms2p29002c9d072738bbf21fb4acf31847e8e@epcms2p6>
2021-06-11  0:28     ` Daejun Park
2021-06-07  4:18 ` [PATCH v36 2/4] scsi: ufs: L2P map management for HPB read Daejun Park
2021-06-11  1:54 ` RE: [PATCH v36 4/4] scsi: ufs: Add HPB 2.0 support Daejun Park

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=20210610062354epcms2p19ed22ed39a4e2fce53dafb8e51b1364f@epcms2p1 \
    --to=daejun7.park@samsung.com \
    --cc=alim.akhtar@samsung.com \
    --cc=asutoshd@codeaurora.org \
    --cc=avri.altman@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=cang@codeaurora.org \
    --cc=d_hyun.kwon@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=huobean@gmail.com \
    --cc=j-young.choi@samsung.com \
    --cc=jaemyung.lee@samsung.com \
    --cc=javier.gonz@samsung.com \
    --cc=jejb@linux.ibm.com \
    --cc=jh.i.park@samsung.com \
    --cc=jieon.seol@samsung.com \
    --cc=keosung.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=stanley.chu@mediatek.com \
    --cc=sungjun07.park@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).