From: "Subhash Jadavani" <subhashj@codeaurora.org>
To: 'Christoph Hellwig' <hch@infradead.org>,
'Dolev Raviv' <draviv@codeaurora.org>
Cc: James.Bottomley@HansenPartnership.com,
linux-scsi@vger.kernel.org, linux-scsi-owner@vger.kernel.org,
linux-arm-msm@vger.kernel.org, santoshsy@gmail.com,
'Sujit Reddy Thumma' <sthumma@codeaurora.org>
Subject: RE: [PATCH V5 10/17] scsi: ufs: manually add well known logical units
Date: Wed, 24 Sep 2014 09:36:37 -0700 [thread overview]
Message-ID: <001101cfd815$b66e0490$234a0db0$@codeaurora.org> (raw)
In-Reply-To: <20140924162444.GA20581@infradead.org>
Comments inline:
-----Original Message-----
From: Christoph Hellwig [mailto:hch@infradead.org]
Sent: Wednesday, September 24, 2014 9:25 AM
To: Dolev Raviv
Cc: James.Bottomley@HansenPartnership.com; hch@infradead.org;
linux-scsi@vger.kernel.org; linux-scsi-owner@vger.kernel.org;
linux-arm-msm@vger.kernel.org; santoshsy@gmail.com; Subhash Jadavani; Sujit
Reddy Thumma
Subject: Re: [PATCH V5 10/17] scsi: ufs: manually add well known logical
units
> /**
> + * ufshcd_set_queue_depth - set lun queue depth
> + * @sdev: pointer to SCSI device
> + *
> + * Read bLUQueueDepth value and activate scsi tagged command
> + * queueing. For WLUN, queue depth is set to 1. For best-effort
> + * cases (bLUQueueDepth = 0) the queue depth is set to a maximum
> + * value that host can queue.
> + */
> +static void ufshcd_set_queue_depth(struct scsi_device *sdev)
I don't think this refactoring belong in here..
[Subhash] I agree, This shouldn't belong here. Will fix it in next patch.
> @@ -2152,8 +2215,6 @@ static int ufshcd_verify_dev_init(struct ufs_hba
> *hba) static int ufshcd_slave_alloc(struct scsi_device *sdev) {
> struct ufs_hba *hba;
> - u8 lun_qdepth;
> - int ret;
>
> hba = shost_priv(sdev->host);
> sdev->tagged_supported = 1;
> @@ -2168,20 +2229,8 @@ static int ufshcd_slave_alloc(struct scsi_device
*sdev)
> /* REPORT SUPPORTED OPERATION CODES is not supported */
> sdev->no_report_opcodes = 1;
>
> - ret = ufshcd_read_unit_desc_param(hba,
> - sdev->lun,
> - UNIT_DESC_PARAM_LU_Q_DEPTH,
> - &lun_qdepth,
> - sizeof(lun_qdepth));
> - if (!ret || !lun_qdepth)
> - /* eventually, we can figure out the real queue depth */
> - lun_qdepth = hba->nutrs;
> - else
> - lun_qdepth = min_t(int, lun_qdepth, hba->nutrs);
>
> - dev_dbg(hba->dev, "%s: activate tcq with queue depth %d\n",
> - __func__, lun_qdepth);
> - scsi_activate_tcq(sdev, lun_qdepth);
> + ufshcd_set_queue_depth(sdev);
>
> return 0;
Addinitional all this setup really belongs into ->slave_configure.
->slave_alloc is just for allocating any needed per-LUN data structure
before scanning, while ->slave_configure is called after a LUN has finished
scanning and is made available. That should be left for a separate patch,
though.
[Subhash] Ok, will fix it and I agree it shouldn't be part of this patch.
> +static int ufshcd_scsi_add_wlus(struct ufs_hba *hba) {
> + int ret = 0;
> +
> + hba->sdev_ufs_device = __scsi_add_device(hba->host, 0, 0,
> + ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN),
NULL);
> + if (IS_ERR(hba->sdev_ufs_device)) {
> + ret = PTR_ERR(hba->sdev_ufs_device);
> + hba->sdev_ufs_device = NULL;
> + goto out;
> + }
Where do you release these references again? It seems like they are never
released on the device removal path.
[Subhash] That's because these are embedded/non-removable UFS devices which
are always present on the board and never get removed. Do you have any
suggestion on how we should handle this?
next prev parent reply other threads:[~2014-09-24 16:36 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 15:13 [PATCH/RESEND V5 00/17] UFS: Power management support Dolev Raviv
2014-09-24 15:13 ` [PATCH V5 01/17] scsi: fixing the "type" for well known LUs Dolev Raviv
2014-09-24 16:04 ` Christoph Hellwig
2014-09-24 20:49 ` Elliott, Robert (Server Storage)
2014-09-25 6:18 ` Subhash Jadavani
2014-09-24 15:13 ` [PATCH V5 02/17] scsi: sysfs: don't add scsi_device if its already added Dolev Raviv
2014-09-24 16:08 ` Christoph Hellwig
2014-09-24 16:27 ` Subhash Jadavani
2014-09-24 16:38 ` 'Christoph Hellwig'
2014-09-25 0:29 ` Subhash Jadavani
2014-09-24 15:13 ` [PATCH/RESEND V5 03/17] scsi: ufs: Allow vendor specific initialization Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 04/17] scsi: ufs: Add regulator enable support Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 05/17] scsi: ufs: Add clock initialization support Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 06/17] scsi: ufs: add voting support for host controller power Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 07/17] scsi: ufs: refactor query descriptor API support Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 08/17] scsi: ufs: improve init sequence Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 09/17] scsi: ufs: Active Power Mode - configuring bActiveICCLevel Dolev Raviv
2014-09-24 15:14 ` [PATCH V5 10/17] scsi: ufs: manually add well known logical units Dolev Raviv
2014-09-24 16:24 ` Christoph Hellwig
2014-09-24 16:36 ` Subhash Jadavani [this message]
2014-09-24 16:40 ` 'Christoph Hellwig'
2014-09-24 16:59 ` Subhash Jadavani
2014-09-24 15:14 ` [PATCH V5 11/17] scsi: ufs: add UFS power management support Dolev Raviv
2014-09-24 23:11 ` Akinobu Mita
2014-09-25 10:35 ` Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 12/17] scsi: ufs: refactor configuring power mode Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 13/17] scsi: ufs: Add support for clock gating Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 14/17] scsi: ufs: Add freq-table-hz property for UFS device Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 15/17] scsi: ufs: Add support for clock scaling using devfreq framework Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 16/17] scsi: ufs: tune bkops while power managment events Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 17/17] scsi: ufs: definitions for phy interface Dolev Raviv
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='001101cfd815$b66e0490$234a0db0$@codeaurora.org' \
--to=subhashj@codeaurora.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=draviv@codeaurora.org \
--cc=hch@infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-scsi-owner@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=santoshsy@gmail.com \
--cc=sthumma@codeaurora.org \
/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).