| Message ID | 1460980193-10085-1-git-send-email-t-kristo@ti.com |
|---|---|
| State | Accepted |
| Commit | 07c5c3ad98926dc15d31aa86de62fd4170f2a745 |
| Headers | show |
On Mon, Apr 18, 2016 at 02:49:53PM +0300, Tero Kristo wrote:
> suspend_prepare can be called during regulator init time also, where
It can be? That seems unexpected...
On 18/04/16 14:59, Mark Brown wrote: > On Mon, Apr 18, 2016 at 02:49:53PM +0300, Tero Kristo wrote: > >> suspend_prepare can be called during regulator init time also, where > > It can be? That seems unexpected... > regulator_register() -> set_machine_constraints() -> suspend_prepare() Called if you have setup initial_state for the regulator. -Tero
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 73b7683..b63302e 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -808,8 +808,6 @@ static int suspend_set_state(struct regulator_dev *rdev, /* locks held by caller */ static int suspend_prepare(struct regulator_dev *rdev, suspend_state_t state) { - lockdep_assert_held_once(&rdev->mutex); - if (!rdev->constraints) return -EINVAL;
suspend_prepare can be called during regulator init time also, where the mutex is not locked yet. This causes a false lockdep warning. To avoid the problem, remove the lockdep assertion from the function causing the issue. An alternative would be to lock the mutex during init, but this would cause other problems (some APIs used during init will attempt to lock the mutex also, causing deadlock.) Signed-off-by: Tero Kristo <t-kristo@ti.com> Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> --- drivers/regulator/core.c | 2 -- 1 file changed, 2 deletions(-) -- 1.7.9.5