Re: [RFC PATCH v3 1/1] scsi: ufs: Enable power management for wlun

From: Asutosh Das <asutoshd@codeaurora.org>
To: Avri Altman <Avri.Altman@wdc.com>
Cc: "cang@codeaurora.org" <cang@codeaurora.org>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	Stanley Chu <stanley.chu@mediatek.com>,
	Bean Huo <beanhuo@micron.com>, Jaegeuk Kim <jaegeuk@kernel.org>,
	Kiwoong Kim <kwmad.kim@samsung.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Satya Tangirala <satyat@google.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v3 1/1] scsi: ufs: Enable power management for wlun
Date: Wed, 17 Feb 2021 14:29:40 -0800	[thread overview]
Message-ID: <20210217222940.GA18897@stor-presley.qualcomm.com> (raw)
In-Reply-To: <20210216173646.GA35819@stor-presley.qualcomm.com>

On Tue, Feb 16 2021 at 09:44 -0800, Asutosh Das wrote:
>On Sat, Feb 13 2021 at 13:37 -0800, Avri Altman wrote:
>>>+       } else {
>>Is it possible to get here?
>>Scsi_scan_host is called only after successful add_wluns
>
>It looks so.
>scsi 0:0:0:49488: Link setup for lun - ufshcd_setup_links
>[...]
>Call trace:
>dump_backtrace+0x0/0x1d4
>show_stack+0x18/0x24
>dump_stack+0xc4/0x144
>ufshcd_setup_links+0xd8/0x100
>ufshcd_slave_alloc+0x134/0x1a0
>scsi_alloc_sdev+0x1c0/0x230
>scsi_probe_and_add_lun+0xc0/0xd48
>__scsi_add_device+0xc0/0x138
>ufshcd_scsi_add_wlus+0x30/0x1c0
>ufshcd_async_scan+0x58/0x240
>async_run_entry_fn+0x48/0x128
>process_one_work+0x1f0/0x470
>worker_thread+0x26c/0x4c8
>kthread+0x13c/0x320
>ret_from_fork+0x10/0x18
>
>>
>>>+               /* device wlun is probed */
>>>+               hba->luns_avail--;
>>>+       }
>>>+}
>>>+
>>
>>
>>>
>>> /**
>>>@@ -7254,6 +7312,14 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba
>>>*hba)
>>>                goto out;
>>>        }
>>>        ufshcd_blk_pm_runtime_init(hba->sdev_ufs_device);
>>>+       /*
>>>+        * A pm_runtime_put_sync is invoked when this device enables
>>>blk_pm_runtime
>>>+        * & would suspend the device-wlun upon timer expiry.
>>>+        * But suspending device wlun _may_ put the ufs device in the pre-defined
>>>+        * low power mode (SSU <rpm_lvl>). Probing of other luns may fail then.
>>>+        * Don't allow this suspend until all the luns have been probed.
>>Maybe add one more sentence: see pm_runtime_mark_last_busy in ufshcd_setup_links
>Done.
>
>>
>>
>>
>>>-       ufshcd_clear_ua_wluns(hba);
>>Are there any callers left to ufshcd_clear_ua_wluns?
>>Can it be removed?
>Let me check.
>
I don't think this can be removed.
The reasoning behind this call as per the commit message indicates that if
there's a reset this request_sense is needed to clear uac.

In pm level 5, the reset would still happen. So I guess this is needed.
Please let me know if I'm missing something here.
The commit message didn't have much details otherwise.

>
>>
>>>+       if (hba->wlun_dev_clr_ua)
>>>+               ufshcd_clear_ua_wlun(hba, UFS_UPIU_UFS_DEVICE_WLUN);
>>>
>>>        cmd[4] = pwr_mode << 4;