> Allow UFS suspend/resume callbacks to run in parallel with other > suspend/resume callbacks. This can recoup dozens of milliseconds on the > resume path if UFS hardware needs to be powered back on. > > Suspending and resuming asynchronously is safe to do so long as the driver > callbacks only depend on resources made available by either a) parent > devices or b) devices explicitly marked as suppliers with device_link_add. > > Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > Cc: Jaegeuk Kim <jaegeuk@xxxxxxxxxx> > Cc: Bart Van Assche <bvanassche@xxxxxxx> > Cc: Adrian Hunter <adrian.hunter@xxxxxxxxx> > Cc: Stanley Chu <stanley.chu@xxxxxxxxxxxx> > Cc: Can Guo <cang@xxxxxxxxxxxxxx> > Cc: Asutosh Das <asutoshd@xxxxxxxxxxxxxx> > Cc: Avri Altman <avri.altman@xxxxxxx> > Cc: Martin K. Petersen <martin.petersen@xxxxxxxxxx> > Signed-off-by: Vincent Palomares <paillon@xxxxxxxxxx> > --- > > Are there any suspend/resume dependencies for UFS drivers not tracked by > the device parent relationship? > > drivers/scsi/ufs/ufshcd.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > index b87ff68aa9aa..9ec5c308a0ea 100644 > --- a/drivers/scsi/ufs/ufshcd.c > +++ b/drivers/scsi/ufs/ufshcd.c > @@ -9625,6 +9625,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem > *mmio_base, unsigned int irq) > async_schedule(ufshcd_async_scan, hba); > ufs_sysfs_add_nodes(hba->dev); > > + device_enable_async_suspend(dev); > return 0; Isn't device_enable_async_suspend is being called for each lun in scsi_sysfs_add_sdev Anyway? Thanks, Avri > > free_tmf_queue: > -- > 2.32.0.432.gabb21c7263-goog
