linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Doug Anderson <dianders@chromium.org>,
	Andy Gross <agross@kernel.org>,
	David Brown <david.brown@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
Date: Thu, 23 May 2019 12:09:25 -0700	[thread overview]
Message-ID: <20190523190925.GU31438@minitux> (raw)
In-Reply-To: <5ce6e0cd.1c69fb81.9a03e.0260@mx.google.com>

On Thu 23 May 11:05 PDT 2019, Stephen Boyd wrote:

> Quoting Doug Anderson (2019-05-23 09:38:13)
> > Hi,
> > 
> > On Tue, Apr 30, 2019 at 9:38 PM Bjorn Andersson
> > <bjorn.andersson@linaro.org> wrote:
> > 
> > > +static int qmp_qdss_clk_add(struct qmp *qmp)
> > > +{
> > > +       struct clk_init_data qdss_init = {
> > > +               .ops = &qmp_qdss_clk_ops,
> > > +               .name = "qdss",
> > > +       };
> > 
> > Can't qdss_init be "static const"?  That had the advantage of not
> > needing to construct it on the stack and also of it having a longer
> > lifetime.  It looks like clk_register() stores the "hw" pointer in its
> > structure and the "hw" structure will have a pointer here.  While I
> > can believe that it never looks at it again, it's nice if that pointer
> > doesn't point somewhere on an old stack.
> > 
> > I suppose we could go the other way and try to mark more stuff in this
> > module as __init and __initdata, but even then at least the pointer
> > won't be onto a stack.  ;-)
> > 
> 
> Const would be nice, but otherwise making it static isn't a good idea.
> The clk_init_data structure is all copied over, although we do leave a
> dangling pointer to it stored inside the clk_hw structure we don't use
> it after clk registration. Maybe we should overwrite the pointer with
> NULL once we're done in clk_register() so that clk providers can't use
> it. It might break somebody but would at least clarify this point.
> 

I had to read through the clock code to conclude that this was indeed
the design, so I'm happy with your patch of ensuring that this is
followed. Perhaps add a statement in the kerneldoc for struct clk_hw as
well to state that init won't be accessed past the return of
clk_register.

> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index aa51756fd4d6..56997a974408 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -3438,9 +3438,9 @@ static int clk_cpy_name(const char **dst_p, const char *src, bool must_exist)
>  	return 0;
>  }
>  
> -static int clk_core_populate_parent_map(struct clk_core *core)
> +static int clk_core_populate_parent_map(struct clk_core *core,
> +					const struct clk_init_data *init)
>  {
> -	const struct clk_init_data *init = core->hw->init;
>  	u8 num_parents = init->num_parents;
>  	const char * const *parent_names = init->parent_names;
>  	const struct clk_hw **parent_hws = init->parent_hws;
> @@ -3520,6 +3520,14 @@ __clk_register(struct device *dev, struct device_node *np, struct clk_hw *hw)
>  {
>  	int ret;
>  	struct clk_core *core;
> +	const struct clk_init_data *init = hw->init;
> +
> +	/*
> +	 * The init data is not supposed to be used outside of registration path.
> +	 * Set it to NULL so that provider drivers can't use it either and so that
> +	 * we catch use of hw->init early on in the core.
> +	 */
> +	hw->init = NULL;
>  
>  	core = kzalloc(sizeof(*core), GFP_KERNEL);
>  	if (!core) {
> @@ -3527,17 +3535,17 @@ __clk_register(struct device *dev, struct device_node *np, struct clk_hw *hw)
>  		goto fail_out;
>  	}
>  
> -	core->name = kstrdup_const(hw->init->name, GFP_KERNEL);
> +	core->name = kstrdup_const(init->name, GFP_KERNEL);
>  	if (!core->name) {
>  		ret = -ENOMEM;
>  		goto fail_name;
>  	}
>  
> -	if (WARN_ON(!hw->init->ops)) {
> +	if (WARN_ON(!init->ops)) {
>  		ret = -EINVAL;
>  		goto fail_ops;
>  	}
> -	core->ops = hw->init->ops;
> +	core->ops = init->ops;
>  
>  	if (dev && pm_runtime_enabled(dev))
>  		core->rpm_enabled = true;
> @@ -3546,13 +3554,13 @@ __clk_register(struct device *dev, struct device_node *np, struct clk_hw *hw)
>  	if (dev && dev->driver)
>  		core->owner = dev->driver->owner;
>  	core->hw = hw;
> -	core->flags = hw->init->flags;
> -	core->num_parents = hw->init->num_parents;
> +	core->flags = init->flags;
> +	core->num_parents = init->num_parents;
>  	core->min_rate = 0;
>  	core->max_rate = ULONG_MAX;
>  	hw->core = core;
>  
> -	ret = clk_core_populate_parent_map(core);
> +	ret = clk_core_populate_parent_map(core, init);
>  	if (ret)
>  		goto fail_parents;
>  

I've reviewed this and it looks good!

Regards,
Bjorn

> 
> > 
> > 
> > > +static void qmp_pd_remove(struct qmp *qmp)
> > > +{
> > > +       struct genpd_onecell_data *data = &qmp->pd_data;
> > > +       struct device *dev = qmp->dev;
> > > +       int i;
> > > +
> > > +       of_genpd_del_provider(dev->of_node);
> > > +
> > > +       for (i = 0; i < data->num_domains; i++)
> > > +               pm_genpd_remove(data->domains[i]);
> > 
> > Still feels like the above loop would be better as:
> >   for (i = data->num_domains - 1; i >= 0; i--)
> > 
> 
> Reason being to remove in reverse order? Otherwise this looks like an
> opinion.

  parent reply	other threads:[~2019-05-23 19:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-01  4:37 [PATCH v7 0/4] Qualcomm AOSS QMP driver Bjorn Andersson
2019-05-01  4:37 ` [PATCH v7 1/4] dt-bindings: soc: qcom: Add AOSS QMP binding Bjorn Andersson
2019-05-01 19:42   ` Rob Herring
2019-05-21 10:42   ` Vinod Koul
2019-05-01  4:37 ` [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver Bjorn Andersson
2019-05-13 14:10   ` Sibi Sankar
2019-05-21  8:08   ` Arun Kumar Neelakantam
2019-05-21 11:10   ` Vinod Koul
2019-05-23 16:38   ` Doug Anderson
2019-05-23 18:05     ` Stephen Boyd
2019-05-23 18:35       ` Doug Anderson
2019-05-23 19:09       ` Bjorn Andersson [this message]
2019-07-30 22:49         ` Stephen Boyd
2019-05-23 19:03     ` Bjorn Andersson
2019-05-25 17:53   ` Sai Prakash Ranjan
2019-05-25 18:17     ` Bjorn Andersson
2019-05-01  4:37 ` [PATCH v7 3/4] arm64: dts: qcom: Add AOSS QMP node Bjorn Andersson
2019-05-21 11:12   ` Vinod Koul
2019-05-23 15:12   ` Doug Anderson
2019-05-01  4:37 ` [PATCH v7 4/4] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
2019-05-21 11:13   ` Vinod Koul

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=20190523190925.GU31438@minitux \
    --to=bjorn.andersson@linaro.org \
    --cc=agross@kernel.org \
    --cc=david.brown@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=swboyd@chromium.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;
as well as URLs for NNTP newsgroup(s).