linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bean Huo (beanhuo)" <beanhuo@micron.com>
To: Bart Van Assche <bvanassche@acm.org>,
	Bean Huo <huobean@gmail.com>,
	"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
	"avri.altman@wdc.com" <avri.altman@wdc.com>,
	"pedrom.sousa@synopsys.com" <pedrom.sousa@synopsys.com>,
	"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
	"tomas.winkler@intel.com" <tomas.winkler@intel.com>,
	"cang@codeaurora.org" <cang@codeaurora.org>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [EXT] Re: [PATCH 2/3] scsi: ufs: initialize max_lu_supported while booting
Date: Sun, 12 Jan 2020 09:52:36 +0000	[thread overview]
Message-ID: <BN7PR08MB56841AD971BEE2F3E13BC4D5DB3A0@BN7PR08MB5684.namprd08.prod.outlook.com> (raw)
In-Reply-To: <95d093b6-591c-1f16-befe-3d192d7c0e2d@acm.org>

Hi, Bart

> > +static int ufshcd_read_geometry_desc(struct ufs_hba *hba, u8 *buf,
> > +u32 size) {
> > +	return ufshcd_read_desc(hba, QUERY_DESC_IDN_GEOMETRY, 0, buf,
> size);
> > +}
> 
> The declaration of this function is longer than its body. Do we really need this
> function? Has it been considered to inline this function into its caller?
>

No, absolutely doesn't need it. ufshcd_read_power_desc() and ufshcd_read_device_desc()
as well. Let me try to simplify them in the next version.
 
> > +static int ufshcd_init_device_param(struct ufs_hba *hba) {
> > +	int err;
> > +	size_t buff_len;
> > +	u8 *desc_buf;
> > +
> > +	buff_len = QUERY_DESC_MAX_SIZE;
> > +	desc_buf = kmalloc(buff_len, GFP_KERNEL);
> > +	if (!desc_buf) {
> > +		err = -ENOMEM;
> > +		goto out;
> > +	}
> 
> Has it been considered to use hba->desc_size.geom_desc instead of
> QUERY_DESC_MAX_SIZE?
>
The reason is that I want all of UFS  device related parameters move to 
ufshcd_init_device_param(), And QUERY_DESC_MAX_SIZE is to compatible
with all of descriptors size. 
 
> > +	err = ufshcd_read_geometry_desc(hba, desc_buf,
> > +			hba->desc_size.geom_desc);
> > +	if (err) {
> > +		dev_err(hba->dev, "%s: Failed reading Geometry Desc. err
> = %d\n",
> > +			__func__, err);
> > +		goto out;
> > +	}
> > +
> > +	if (desc_buf[GEOMETRY_DESC_PARAM_MAX_NUM_LUN] == 1)
> > +		hba->dev_info.max_lu_supported = 32;
> > +	else if (desc_buf[GEOMETRY_DESC_PARAM_MAX_NUM_LUN] == 0)
> > +		hba->dev_info.max_lu_supported = 8;
> 
> Can it happen that GEOMETRY_DESC_PARAM_MAX_NUM_LUN >=
> hba->desc_size.geom_desc and hence that the above code reads
> uninitialized data?
> 
No, GEOMETRY_DESC_PARAM_MAX_NUM_LUN 0x0c is far less than geometry descriptor size.
As for the  UFS 2.0, this field is reserved, it is default 0.  For the UFS 2.1 and UFS 3.0, there are only
two valid value for this filed, either 00h: 8 Logical units, or 01h: 32 Logical units.

> > @@ -7016,13 +7052,22 @@ static int ufshcd_probe_hba(struct ufs_hba
> > *hba)
> >
> >  	/*
> >  	 * If we are in error handling context or in power management callbacks
> > -	 * context, no need to scan the host
> > +	 * context, no need to scan the host and to reinitialize the
> > +parameters
> >  	 */
> >  	if (!ufshcd_eh_in_progress(hba) && !hba->pm_op_in_progress) {
> >  		bool flag;
> >
> >  		/* clear any previous UFS device information */
> >  		memset(&hba->dev_info, 0, sizeof(hba->dev_info));
> > +		/* Init parameters according to UFS relevant descriptors */
> > +		ret = ufshcd_init_device_param(hba);
> > +		if (ret) {
> > +			dev_err(hba->dev,
> > +				"%s: Init of device param failed. err = %d\n",
> > +				__func__, ret);
> > +			goto out;
> > +		}
> > +
> >  		if (!ufshcd_query_flag_retry(hba,
> UPIU_QUERY_OPCODE_READ_FLAG,
> >  				QUERY_FLAG_IDN_PWR_ON_WPE, &flag))
> >  			hba->dev_info.f_power_on_wp_en = flag;
> 
> The context check in ufshcd_probe_hba() looks ugly to me. Has it been
> considered to move all code that is controlled by the if-statement with the
> context check into ufshcd_async_scan()?
> 
I totally agree with you. They should be moved out from ufshcd_probe_hba(), 
And moved to ufshcd_async_scan(). Let me do in the next version. 

Thanks.

//Bean Huo 


  parent reply	other threads:[~2020-01-12  9:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 18:36 [PATCH v1 0/3] use UFS device indicated maximum LU number Bean Huo
2020-01-10 18:36 ` [PATCH 1/3] scsi: ufs: add max_lu_supported in struct ufs_dev_info Bean Huo
2020-01-11 22:43   ` Bart Van Assche
2020-01-13 18:43   ` asutoshd
2020-01-10 18:36 ` [PATCH 2/3] scsi: ufs: initialize max_lu_supported while booting Bean Huo
2020-01-11 22:42   ` Bart Van Assche
2020-01-12  8:41     ` Avri Altman
2020-01-12  9:52     ` Bean Huo (beanhuo) [this message]
2020-01-13 18:44   ` asutoshd
2020-01-10 18:36 ` [PATCH 3/3] scsi: ufs: use UFS device indicated maximum LU number Bean Huo
2020-01-11 22:50   ` Bart Van Assche
2020-01-13 18:45   ` asutoshd

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=BN7PR08MB56841AD971BEE2F3E13BC4D5DB3A0@BN7PR08MB5684.namprd08.prod.outlook.com \
    --to=beanhuo@micron.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=cang@codeaurora.org \
    --cc=huobean@gmail.com \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=pedrom.sousa@synopsys.com \
    --cc=stanley.chu@mediatek.com \
    --cc=tomas.winkler@intel.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).