Re: [PATCH 1/3] regulator: Add notifier event on regulator disable

[Jeffrey Carlyle]

On Mon, Jan 4, 2010 at 12:17 PM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> The intended use case is for drivers which disable regulators to save
> power but need to do some work to restore the hardware state when
> restarting.  If the supplies are not actually disabled due to board
> limits or sharing with other active devices this notifier allows the
> driver to avoid unneeded reinitialisation, particularly when used with
> runtime PM.
>
> Signed-off-by: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> ---
>  drivers/regulator/core.c           |    7 +++++--
>  include/linux/regulator/consumer.h |    4 +++-
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 686ef27..cce76a8 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -1341,6 +1341,9 @@ static int _regulator_disable(struct regulator_dev *rdev)
>                                       __func__, rdev_get_name(rdev));
>                                return ret;
>                        }
> +
> +                       _notifier_call_chain(rdev, REGULATOR_EVENT_DISABLE,
> +                                            NULL);
>                }
>
>                /* decrease our supplies ref count and disable if required */
> @@ -1399,8 +1402,8 @@ static int _regulator_force_disable(struct regulator_dev *rdev)
>                        return ret;
>                }
>                /* notify other consumers that power has been forced off */
> -               _notifier_call_chain(rdev, REGULATOR_EVENT_FORCE_DISABLE,
> -                       NULL);
> +               _notifier_call_chain(rdev, REGULATOR_EVENT_FORCE_DISABLE |
> +                       REGULATOR_EVENT_DISABLE, NULL);
>        }
>
>        /* decrease our supplies ref count and disable if required */
> diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
> index 030d922..28c9fd0 100644
> --- a/include/linux/regulator/consumer.h
> +++ b/include/linux/regulator/consumer.h
> @@ -89,8 +89,9 @@
>  * REGULATION_OUT Regulator output is out of regulation.
>  * FAIL           Regulator output has failed.
>  * OVER_TEMP      Regulator over temp.
> - * FORCE_DISABLE  Regulator shut down by software.
> + * FORCE_DISABLE  Regulator forcibly shut down by software.
>  * VOLTAGE_CHANGE Regulator voltage changed.
> + * DISABLE        Regulator was disabled.
>  *
>  * NOTE: These events can be OR'ed together when passed into handler.
>  */
> @@ -102,6 +103,7 @@
>  #define REGULATOR_EVENT_OVER_TEMP              0x10
>  #define REGULATOR_EVENT_FORCE_DISABLE          0x20
>  #define REGULATOR_EVENT_VOLTAGE_CHANGE         0x40
> +#define REGULATOR_EVENT_DISABLE                0x80
>
>  struct regulator;
>
> --
> 1.6.5.7

Mark et al, sorry to drag up something from nine months ago, but I'm
having a problem with this patch. I have a regulator A that sets
regulator B as its supply. When I call set_supply to add B as the
supply for A, regulator A gets added to the supply_list for regulator
B.

When I call regulator_disable(A), I end up with a call chain like this:

regulator_disable(A)
- mutex_lock(A)
- _regulator_disable(A)
-- _regulator_disable(B)
--- _notifier_call_chain(B)
---- mutex_lock(A)

Which results in dead lock since we trying to acquire the mutex lock
for regulator A which we already hold.

When I call regulator_disable(A), regulator_disable grabs the
mutex_lock for A. Then while inside _regulator_disable,
regulator_disable(B) is called since B is the supply for A. With this
patch, _regulator_disable(B) ends up calling _notifier_call_chain(B).
A is in the supply_list for B, so inside the notifier loop we try to
grab the mutext_lock for A again.

Am I doing something wrong in how I am setting up B as the supply for
A or is this bug in the regulator core code?

Thanks,
 - Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/