public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mturquette@linaro.org (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] clk: Don't hold prepare_lock across debugfs creation
Date: Wed, 10 Sep 2014 14:43:17 -0700	[thread overview]
Message-ID: <20140910214317.19023.44430@quantum> (raw)
In-Reply-To: <20140906000000.GB22593@codeaurora.org>

Quoting Stephen Boyd (2014-09-05 17:00:00)
> On 09/04, Stephen Boyd wrote:
> > 
> > I don't understand why we need to hold the prepare lock around
> > the kref_put(), so I changed the flow so that we don't do this
> > when we unregister a clock.
> 
> Ok we hold the prepare mutex to make sure get and put are serialized.
> Good. Here's the interdiff to move the debugfs unregistration before
> the prepare lock and detect double unregisters without holding
> the prepare lock.

Looks good to me. I've rolled this into the original above and applied
it to clk-next.

Regards,
Mike

> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 3c04d0d69b96..8ca28189e4e9 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -338,10 +338,14 @@ unlock:
>  static void clk_debug_unregister(struct clk *clk)
>  {
>         mutex_lock(&clk_debug_lock);
> -       hlist_del_init(&clk->debug_node);
> -       mutex_unlock(&clk_debug_lock);
> +       if (!clk->dentry)
> +               goto out;
>  
> +       hlist_del_init(&clk->debug_node);
>         debugfs_remove_recursive(clk->dentry);
> +       clk->dentry = NULL;
> +out:
> +       mutex_unlock(&clk_debug_lock);
>  }
>  
>  struct dentry *clk_debugfs_add_file(struct clk *clk, char *name, umode_t mode,
> @@ -2065,14 +2069,15 @@ void clk_unregister(struct clk *clk)
>  {
>         unsigned long flags;
>  
> -       if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
> -               return;
> +       if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
> +               return;
> +
> +       clk_debug_unregister(clk);
>  
>         clk_prepare_lock();
>  
>         if (clk->ops == &clk_nodrv_ops) {
>                 pr_err("%s: unregistered clock: %s\n", __func__, clk->name);
> -               clk_prepare_unlock();
>                 return;
>         }
>         /*
> @@ -2097,11 +2102,9 @@ void clk_unregister(struct clk *clk)
>         if (clk->prepare_count)
>                 pr_warn("%s: unregistering prepared clock: %s\n",
>                                         __func__, clk->name);
> -       clk_prepare_unlock();
> -
> -       clk_debug_unregister(clk);
> -
>         kref_put(&clk->ref, __clk_release);
> +
> +       clk_prepare_unlock();
>  }
>  EXPORT_SYMBOL_GPL(clk_unregister);
>  
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation

      reply	other threads:[~2014-09-10 21:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05  0:46 ccf vs iommu vs drm locking fun Rob Clark
2014-09-05  1:15 ` Stephen Boyd
2014-09-05  1:23 ` [PATCH 1/2] clk: Make __clk_lookup() use a list instead of tree search Stephen Boyd
2014-09-05  1:23   ` [PATCH 2/2] clk: Don't hold prepare_lock across debugfs creation Stephen Boyd
2014-09-05  6:02   ` [PATCH 1/2] clk: Make __clk_lookup() use a list instead of tree search Stephen Boyd
2014-09-05  6:37 ` [PATCH v2] clk: Don't hold prepare_lock across debugfs creation Stephen Boyd
2014-09-06  0:00   ` Stephen Boyd
2014-09-10 21:43     ` Mike Turquette [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140910214317.19023.44430@quantum \
    --to=mturquette@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox