linux-kernel - Re: [PATCH] regulator: disable supply regulator if it is enabled for boot-on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH+eYFC5WPbwrfMh9tN2ocQOj46a2E2QmjYCLvk2_zHOVCGP1Q@mail.gmail.com>
Date:	Tue, 14 Aug 2012 13:08:38 +0200
From:	Rabin Vincent <rabin@....in>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	broonie@...nsource.wolfsonmicro.com, lrg@...com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: disable supply regulator if it is enabled for boot-on

2012/8/14 Laxman Dewangan <ldewangan@...dia.com>:
> If supply regulator is enabled because of boot-on (not always-on)
> then disable regulator need to be call if regulator have some
> user or full constraint has been enabled.
> This will make sure that reference count of supply regulator
> is in sync with child regulator's state.
>
> Signed-off-by: Laxman Dewangan <ldewangan@...dia.com>

 =============================================
 [ INFO: possible recursive locking detected ]
 3.4.0+ #71 Not tainted
 ---------------------------------------------
 swapper/0/1 is trying to acquire lock:
  (&rdev->mutex){+.+.+.}, at: [<c0306c60>] regulator_disable+0x2c/0x6c

 but task is already holding lock:
  (&rdev->mutex){+.+.+.}, at: [<c0a0d1f4>] regulator_init_complete+0x70/0x1c0

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&rdev->mutex);
   lock(&rdev->mutex);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 2 locks held by swapper/0/1:
  #0:  (regulator_list_mutex){+.+.+.}, at: [<c0a0d1a8>]
regulator_init_complete+0x24/0x1c0
  #1:  (&rdev->mutex){+.+.+.}, at: [<c0a0d1f4>]
regulator_init_complete+0x70/0x1c0

 stack backtrace:
 [<c0017ab4>] (unwind_backtrace+0x0/0x148) from [<c06e86a0>]
(dump_stack+0x20/0x24)
 [<c06e86a0>] (dump_stack+0x20/0x24) from [<c008e6d0>]
(check_deadlock+0x358/0x44c)
 [<c008e6d0>] (check_deadlock+0x358/0x44c) from [<c008f7b4>]
(validate_chain+0x410/0x710)
 [<c008f7b4>] (validate_chain+0x410/0x710) from [<c0090034>]
(__lock_acquire+0x580/0xb3c)
 [<c0090034>] (__lock_acquire+0x580/0xb3c) from [<c0090690>]
(lock_acquire+0xa0/0x138)
 [<c0090690>] (lock_acquire+0xa0/0x138) from [<c06ea0d0>]
(mutex_lock_nested+0x5c/0x364)
 [<c06ea0d0>] (mutex_lock_nested+0x5c/0x364) from [<c0306c60>]
(regulator_disable+0x2c/0x6c)
 [<c0306c60>] (regulator_disable+0x2c/0x6c) from [<c0a0d2cc>]
(regulator_init_complete+0x148/0x1c0)
 [<c0a0d2cc>] (regulator_init_complete+0x148/0x1c0) from [<c0008644>]
(do_one_initcall+0x50/0x1a8)
 [<c0008644>] (do_one_initcall+0x50/0x1a8) from [<c09ee3dc>]
(kernel_init+0xf4/0x1d4)
 [<c09ee3dc>] (kernel_init+0xf4/0x1d4) from [<c0010cfc>]
(kernel_thread_exit+0x0/0x8)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/