Hi Liam and Mark, I was analyzing the mutex lock usage in drivers/regulator/core.c and found at least one way to reach deadlock: regulator_enable is called for a regulator at the same time that regulator_disable is called for that regulator's supply. Consider this simple example. There are two regulators: S1 and L2, as well as two consumers: A and B. They are connected as follows: S1 --> L2 --> B | |--> A Assume that A has already called regulator_enable for S1 some time in the past. Consumer A thread execution: regulator_disable(S1) mutex_lock(S1) _regulator_disable(S1) _notifier_call_chain(S1) mutex_lock(L2) Consumer B thread execution: regulator_enable(L2) mutex_lock(L2) _regulator_enable(L2) mutex_lock(S1) The locks for S1 and L2 are taken in opposite orders in the two threads; therefore, it is possible to achieve deadlock. I am not sure about the best way to resolve this situation. Is there a correctness requirement that regulator_enable holds the child regulator's lock when it attempts to enable the parent regulator? Likewise, is the lock around _notifier_call_chain required? Thanks, David Collins -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
