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.
+ if (hba->wlun_dev_clr_ua)
+ ufshcd_clear_ua_wlun(hba, UFS_UPIU_UFS_DEVICE_WLUN);
cmd[4] = pwr_mode << 4;
