From 09460e01389a884f5fb6b8932bf88710c57e0da3 Mon Sep 17 00:00:00 2001 From: Asutosh Das Date: Tue, 14 Nov 2017 17:01:40 +0530 Subject: [PATCH] scsi: ufs: Trigger runtime-idle in a separate work In case of an exception, there could be a deadlock: -000|__switch_to() -001|context_switch(inline) -001|__schedule() -002|schedule() -003|schedule_timeout() -004|do_wait_for_common(inline) -004|__wait_for_common(inline) -004|wait_for_common() -005|wait_for_completion() -006|destroy_work_on_stack(inline) -006|flush_work() -007|ufshcd_suspend() -008|ufshcd_runtime_suspend() -009|ufshcd_pltfrm_runtime_suspend() -010|pm_generic_runtime_suspend() -011|__rpm_callback(inline) -011|rpm_callback() -012|rpm_suspend() -013|rpm_idle() -014|__pm_runtime_idle() -015|ufshcd_exception_event_handler() -016|__read_once_size(inline) -016|static_key_count(inline) -016|static_key_false(inline) -016|trace_workqueue_execute_end(inline) -016|process_one_work() -017|__read_once_size(inline) -017|list_empty(inline) -017|worker_thread() -018|kthread() -019|ret_from_fork(asm) This is caused because in exception handler pm_runtime_put_sync is invoked which calls ufshcd_suspend. And ufshcd_suspend flushes the exception handler work & deadlocks. Hence, schedule the suspend work in a different context. Change-Id: I02524cee5ab2b64e0ad5de873d5318aef7b6ac95 Signed-off-by: Asutosh Das Signed-off-by: Sayali Lokhande --- drivers/scsi/ufs/ufshcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 7fd8ffe17707..8ee607606866 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -5980,7 +5980,7 @@ static void ufshcd_exception_event_handler(struct work_struct *work) out: ufshcd_scsi_unblock_requests(hba); - pm_runtime_put_sync(hba->dev); + pm_runtime_put(hba->dev); return; }