Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp115468ybg; Mon, 8 Jun 2020 18:02:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhVaLY2xXJilEgtCbQ34NzONhNtfD9mffaavN0GyvdnUZ0imSsS+Y4OHwl8mBeJRI9oOZh X-Received: by 2002:a17:906:a398:: with SMTP id k24mr22332136ejz.220.1591664563783; Mon, 08 Jun 2020 18:02:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591664563; cv=none; d=google.com; s=arc-20160816; b=oIWpeam74U+UHOydjUHkVYsHOjgzanydbd8lthhpikkxnlnq9/SNan6zAgHB46aDZi b+6zxRzSllCEabYhZfOjtrfOjk0jhzqCHSSCS1hlGCrtshIkw3stgwlVmuSaFBgXdqpa KG8HvMvyzUqKbdKczM24Cz9XCFMVURA+XxxFtz+PymTb6LMPJOkFMa5v1+PEdo2tN4PV jI+4S0tyou9qYkGanAi/mk88Ih+Y3ErwOtEEUlTezHjhA5ejxhIddb0wjM6kls+HDF0u koEwNcr5ORrCgEaYFhIbSJyUGDLEGLKv4whbOxq4E3DsrucUdjxIzuAlPPhjuPdOxYDe ImPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:content-transfer-encoding:date :message-id:in-reply-to:cc:to:from:reply-to:subject:mime-version :dkim-signature:dkim-filter; bh=2ZdGa0WusYMlSIsrK40ujqb//hV2zjpeCw+1vy1+wno=; b=nrh4wQSeKdW6Cj+54aOH+aWz/mPNCnMzjTtK0+WWcb7uJI9QpKZbBd6fQnZWNgmHUm FQHuX4sPjFsM5lAQLvTzKj1ZFhsh6UhKv3saX9PpKNopxGJcHhEO7YdROPnoSgebsZss bl0mkj7u5VRD9OF+knPr7pXft8pY5/7r5DoxdtRc0DsxoaQjq60YlYyh0Canq7pcRErP Ee15+RA3LvHvWp2EJVICr7JrWD8uiWCrySBmdzwDfHQV5fLBWU48GXt0KFBJGcZLHLDs s59ytasB/yx8+mgtJTqmcoO/wkmfjrCAY1BDF4G9r2xlpzcoTbHSFzIgJjfoqcLg8C2H yRnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b=lUQuojRA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w11si10398902edl.171.2020.06.08.18.02.20; Mon, 08 Jun 2020 18:02:43 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b=lUQuojRA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729075AbgFIA6a (ORCPT + 99 others); Mon, 8 Jun 2020 20:58:30 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:41473 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731457AbgFIA6G (ORCPT ); Mon, 8 Jun 2020 20:58:06 -0400 Received: from epcas1p1.samsung.com (unknown [182.195.41.45]) by mailout3.samsung.com (KnoxPortal) with ESMTP id 20200609005803epoutp03118cd5747593e8521b95bb84e2605d9d~Wujumotjq0060500605epoutp03H for ; Tue, 9 Jun 2020 00:58:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout3.samsung.com 20200609005803epoutp03118cd5747593e8521b95bb84e2605d9d~Wujumotjq0060500605epoutp03H DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1591664283; bh=2ZdGa0WusYMlSIsrK40ujqb//hV2zjpeCw+1vy1+wno=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=lUQuojRAhoL4rHeXG7n0bTdESy12gPbTkpXQjPnrESB2AD6/5bvHQZlPj89yA8mui TdVv2+62cYbaj99d1BbhIuUB0N+pruN8a8D+fby8t1BLVrpd+n4VY5ORGN33247iNY jx9xxEigqC9M1s4DJxym+C8suWhafIz4h0Oj9Ncw= Received: from epcpadp2 (unknown [182.195.40.12]) by epcas1p3.samsung.com (KnoxPortal) with ESMTP id 20200609005803epcas1p3a8278aac6a6ccf493793ac8f95954dd0~WujuEQ_8W1119911199epcas1p3b; Tue, 9 Jun 2020 00:58:03 +0000 (GMT) Mime-Version: 1.0 Subject: RE: [RFC PATCH 3/5] scsi: ufs: Introduce HPB module Reply-To: daejun7.park@samsung.com From: Daejun Park To: Avri Altman , Daejun Park , ALIM AKHTAR , "jejb@linux.ibm.com" , "martin.petersen@oracle.com" , "asutoshd@codeaurora.org" , "beanhuo@micron.com" , "stanley.chu@mediatek.com" , "cang@codeaurora.org" , "bvanassche@acm.org" , "tomas.winkler@intel.com" CC: "linux-scsi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Sang-yoon Oh , Sung-Jun Park , yongmyung lee , Jinyoung CHOI , Adel Choi , BoRam Shin X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: X-CPGS-Detection: blocking_info_exchange X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <1431530910.81591664283090.JavaMail.epsvc@epcpadp2> Date: Tue, 09 Jun 2020 09:52:01 +0900 X-CMS-MailID: 20200609005201epcms2p82af5353727f989c2cf3da468f756bd2e Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: AUTO_CONFIDENTIAL X-CPGSPASS: Y X-CPGSPASS: Y X-Hop-Count: 3 X-CMS-RootMailID: 20200605011604epcms2p8bec8ef6682583d7248dc7d9dc1bfc882 References: <336371513.41591320902369.JavaMail.epsvc@epcpadp1> <963815509.21591320301642.JavaMail.epsvc@epcpadp1> <231786897.01591320001492.JavaMail.epsvc@epcpadp1> <231786897.01591322101492.JavaMail.epsvc@epcpadp1> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Why not just allow for max-active-regions per the device's configuration? > The platform vendor can provision it per its need. The max-active-region is configured as device config. The module parameter = which you mentioned is just minimum value of the memory pool. > > + > > + total_srgn_cnt =3D hpb->srgns_per_lu; > > + for (rgn_idx =3D 0, srgn_cnt =3D 0; rgn_idx < hpb->rgns_per_lu; > > + rgn_idx++, total_srgn_cnt -=3D srgn_cnt) { > Maybe simplify and improve readability by moving the srgn_cnt into the fo= r clause: > =09int srgn_cnt =3D hpb->srgns_per_rgn; OK, I will apply this for patch v2. > > + > > +static void ufshpb_destroy_region_tbl(struct ufshpb_lu *hpb) > > +{ > > + int rgn_idx; > > + > > + for (rgn_idx =3D 0; rgn_idx < hpb->rgns_per_lu; rgn_idx++) { > > + struct ufshpb_region *rgn; > > + > > + rgn =3D hpb->rgn_tbl + rgn_idx; > > + if (rgn->rgn_state !=3D HPB_RGN_INACTIVE) { > > + rgn->rgn_state =3D HPB_RGN_INACTIVE; > > + > > + ufshpb_destroy_subregion_tbl(hpb, rgn); > > + } > > + > > + kvfree(rgn->srgn_tbl); > This looks like it belongs to ufshpb_destroy_subregion_tbl? Yes, it will be changed. > How about calling ufshpb_issue_hpb_reset_query right after ufshpb_get_dev= _info? > This way waiting for the device to complete its reset can be done while s= csi is scanning the luns? I will change the call path as follows: - ufshpb_probe_async - ufshpb_get_dev_info =EF=83=A0 - ufshpb_issue_hpb_reset_query 1/2 (query part) - ufshpb_scan_hpb_lu =EF=83=A0 - ufshpb_issue_hpb_reset_query 2/2 (wait part) > > + > > +static void ufshpb_reset(struct ufs_hba *hba) > > +static void ufshpb_reset_host(struct ufs_hba *hba) > > +static void ufshpb_suspend(struct ufs_hba *hba) > > +static void ufshpb_resume(struct ufs_hba *hba) > The above 4 functions essentially runs the same code but set a different = state. > Maybe call a helper? OK, I will. > > +static int ufshpb_create_sysfs(struct ufs_hba *hba, struct ufshpb_lu *= hpb) > Why separate from ufs-sysfs? > Also you might want to introduce all the stats not as part of the functio= nal patch. The HPB feature is implemented as a device. So, We added the hpb-sysfs sepa= rated from ufs-sysfs. > > + > > +static int ufshpb_get_geo_info(struct ufs_hba *hba, u8 *geo_buf, > > + struct ufshpb_dev_info *hpb_dev_info) > > +{ > > + int hpb_device_max_active_rgns =3D 0; > > + int hpb_num_lu; > > + > > + hpb_dev_info->max_num_lun =3D > > + geo_buf[GEOMETRY_DESC_PARAM_MAX_NUM_LUN] =3D=3D 0x00 ? = 8 : > > 32; > You already have this in hba->dev_info.max_lu_supported > > + > > + hpb_num_lu =3D geo_buf[GEOMETRY_DESC_HPB_NUMBER_LU]; > You should capture hpb_dev_info->max_num_lun =3D hpb_num_lu You are right. And hpb_dev_info->max_num_lun will be deleted. > > + > > + ret =3D ufshpb_read_desc(hba, QUERY_DESC_IDN_DEVICE, 0, SELECTO= R, > > + desc_buf, hba->desc_size.dev_desc); > What with this SELECTOR stuff? > Why not the default 0? Right, SELECTOR should be 0. I will fix it.=20 > What about the other hpb fields in the device descriptor: > DEVICE_DESC_PARAM_HPB_VER and DEVICE_DESC_PARAM_HPB_CONTROL ? I will add codes that checks these fields on initialization. > > +unsigned int ufshpb_host_map_kbytes =3D 1 * 1024; > > +module_param(ufshpb_host_map_kbytes, uint, 0644); > > +MODULE_PARM_DESC(ufshpb_host_map_kbytes, > > + "ufshpb host mapping memory kilo-bytes for ufshpb memory-pool"= ); > You should introduce this module parameter in the patch that uses it. OK, could you recommend good location of introducing message? At the patch = letter or in the codes? Thanks, Daejun