From: Bart Van Assche <bvanassche@acm.org>
To: Bean Huo <beanhuo@iokpp.de>,
alim.akhtar@samsung.com, avri.altman@wdc.com,
asutoshd@codeaurora.org, jejb@linux.ibm.com,
martin.petersen@oracle.com, stanley.chu@mediatek.com,
beanhuo@micron.com, tomas.winkler@intel.com, cang@codeaurora.org,
daejun7.park@samsung.com, huobean@gmail.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] scsi: ufs: core: Cleanup ufshcd_slave_alloc()
Date: Tue, 18 Oct 2022 11:27:25 -0700 [thread overview]
Message-ID: <9868763a-d360-db53-02b9-2d7ab9628d79@acm.org> (raw)
In-Reply-To: <20221018181627.326657-3-beanhuo@iokpp.de>
On 10/18/22 11:16, Bean Huo wrote:
> +static void ufshcd_lu_init(struct ufs_hba *hba, struct scsi_device *sdev)
> +{
> + u8 lun_qdepth;
> + u8 *desc_buf;
> + int ret;
> + int len;
> + u8 lun;
> +
> + lun_qdepth = hba->nutrs;
> + lun = ufshcd_scsi_to_upiu_lun(sdev->lun);
> + len = hba->desc_size[QUERY_DESC_IDN_UNIT];
Isn't the preferred style for kernel code to combine the above
declarations and assignments (but not memory allocation calls)?
> + desc_buf = kzalloc(len, GFP_KERNEL);
> + if (!desc_buf)
> + goto set_qdepth;
> +
> + ret = ufshcd_read_unit_desc_param(hba, lun, 0, desc_buf, len);
> + if (ret < 0) {
> + if (ret == -EOPNOTSUPP)
> + /* If LU doesn't support unit descriptor, its queue depth is set to 1 */
> + lun_qdepth = 1;
> + kfree(desc_buf);
> + goto set_qdepth;
> + }
> +
> + if (desc_buf[UNIT_DESC_PARAM_LU_Q_DEPTH])
> + /*
> + * In per-LU queueing architecture, bLUQueueDepth will not be 0, then we will
> + * use the smaller between UFSHCI CAP.NUTRS and UFS LU bLUQueueDepth
> + */
> + lun_qdepth = min_t(int, desc_buf[UNIT_DESC_PARAM_LU_Q_DEPTH], hba->nutrs);
Should a test be added that verifies that UNIT_DESC_PARAM_LU_Q_DEPTH < len?
Additionally, please use braces ({}) around multi-line if-statement bodies.
> + /*
> + * According to UFS device specification, the write protection mode is only supported by
> + * normal LU, not supported by WLUN.
> + */
> + if (hba->dev_info.f_power_on_wp_en && lun < hba->dev_info.max_lu_supported &&
> + !hba->dev_info.is_lu_power_on_wp &&
> + desc_buf[UNIT_DESC_PARAM_LU_WR_PROTECT] == UFS_LU_POWER_ON_WP)
> + hba->dev_info.is_lu_power_on_wp = true;
Also here, should the following test be added:
UNIT_DESC_PARAM_LU_WR_PROTECT < len?
Otherwise this patch looks good to me.
Thanks,
Bart.
next prev parent reply other threads:[~2022-10-18 18:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 18:16 [PATCH v3 0/3] Changes for ufshcd.c Bean Huo
2022-10-18 18:16 ` [PATCH v3 1/3] scsi: ufs: core: Remove unnecessary if statement Bean Huo
2022-10-18 18:20 ` Bart Van Assche
2022-10-18 18:23 ` Bean Huo
2022-10-18 18:16 ` [PATCH v3 2/3] scsi: ufs: core: Cleanup ufshcd_slave_alloc() Bean Huo
2022-10-18 18:27 ` Bart Van Assche [this message]
2022-10-22 21:30 ` Bean Huo
2022-10-18 18:16 ` [PATCH v3 3/3] scsi: ufs: core: Use is_visible to control UFS unit descriptor sysfs nodes Bean Huo
2022-10-18 18:23 ` Bart Van Assche
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=9868763a-d360-db53-02b9-2d7ab9628d79@acm.org \
--to=bvanassche@acm.org \
--cc=alim.akhtar@samsung.com \
--cc=asutoshd@codeaurora.org \
--cc=avri.altman@wdc.com \
--cc=beanhuo@iokpp.de \
--cc=beanhuo@micron.com \
--cc=cang@codeaurora.org \
--cc=daejun7.park@samsung.com \
--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=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
all inboxes | Powered by JetHome®