linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Jerome Brunet <jbrunet@baylibre.com>,
	Michael Turquette <mturquette@baylibre.com>
Cc: linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Russell King <linux@armlinux.org.uk>,
	Jeffrey Hugo <jhugo@codeaurora.org>, Chen-Yu Tsai <wens@csie.org>
Subject: Re: [PATCH v2 6/8] clk: Allow parents to be specified without string names
Date: Fri, 15 Mar 2019 10:16:59 -0700	[thread overview]
Message-ID: <155267021941.20095.16439182841724325601@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <3e6aa4c392ccdd3bac76b556645139536e61e5e6.camel@baylibre.com>

Quoting Jerome Brunet (2019-03-15 03:01:53)
> On Tue, 2019-02-26 at 14:34 -0800, Stephen Boyd wrote:
> > ---
> >  drivers/clk/clk.c            | 260 ++++++++++++++++++++++++++---------
> >  include/linux/clk-provider.h |  19 +++
> >  2 files changed, 217 insertions(+), 62 deletions(-)
> 
> Sorry for the delay.
> 
> With the fix you sent to Jeffrey
> Tested by porting the aoclk controller of Amlogic g12a SoC.
> This allowed to test
>  * hws only table
>  * parent_data with a mix of hw pointers and fw_name (with different input
> controllers and also an input that is optional and never provided)
> 
> Tested-by: Jerome Brunet <jbrunet@baylibre.com>
> 
> With the small comment below
> 
> Reviewed-by Jerome Brunet <jbrunet@baylibre.com>
> 

Awesome. Thanks! I need to Cc Rob H to hopefully get an ack on the
concept of relying on DT so I'll resend this series again next week. It
would also be nice if I can throw in a couple more patches to let
drivers specify a DT node when registering a clk if they don't have a
struct device on hand and let drivers lookup with clk_lookups somehow.

> 
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 937b8d092d17..3d01e8c56400 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -39,6 +39,13 @@ static LIST_HEAD(clk_notifier_list);
> >  
> 
> [...]
> 
> >  
> > +static int clk_cpy_name(const char *dst, const char *src, bool must_exist)
> > +{
> > +     if (!src) {
> > +             if (must_exist)
> > +                     return -EINVAL;
> > +             return 0;
> > +     }
> > +
> > +     dst = kstrdup_const(src, GFP_KERNEL);
> > +     if (!dst)
> > +             return -ENOMEM;
> > +
> > +     return 0;
> > +}
> > +
> > +static int clk_core_populate_parent_map(struct clk_core *core)
> > +{
> > +     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;
> > +     const struct clk_parent_data *parent_data = init->parent_data;
> > +     int i, ret = 0;
> > +     struct clk_parent_map *parents, *parent;
> > +
> > +     if (!num_parents)
> > +             return 0;
> > +
> > +     /*
> > +      * Avoid unnecessary string look-ups of clk_core's possible parents by
> > +      * having a cache of names/clk_hw pointers to clk_core pointers.
> > +      */
> > +     parents = kcalloc(num_parents, sizeof(*parents), GFP_KERNEL);
> > +     core->parents = parents;
> > +     if (!parents)
> > +             return -ENOMEM;
> > +
> > +     /* Copy everything over because it might be __initdata */
> > +     for (i = 0, parent = parents; i < num_parents; i++, parent++) {
> > +             if (parent_names) {
> > +                     /* throw a WARN if any entries are NULL */
> > +                     WARN(!parent_names[i],
> > +                             "%s: invalid NULL in %s's .parent_names\n",
> > +                             __func__, core->name);
> > +                     ret = clk_cpy_name(parent->name, parent_names[i],
> > +                                        true);
> > +             } else if (parent_data) {
> 
> While testing, I mistakenly left both parent_names and parent_data. I was
> surprised that parent_data did not take precedence of parent_names.
> 
> Maybe it should ? (... but I understand we are not supposed to provide both)

I don't think we can. We have a problem where drivers don't initialize
the init structure properly, opting to just throw it on the stack and
leave junk in there that they overwrite. We'd have to go through all the
init structures and initialize them. I suppose we could make a macro for
that:

	DECLARE_CLK_INIT_DATA(init);

or something like that that does this. We could bury a magic number in
there under some debug option too so that we can make sure drivers are
doing this properly. Otherwise we're left to doing these weird tricks
like I've done here.

Regardless. I'll have to add a comment to this fact in the code. Thanks.

> 
> > +                     parent->hw = parent_data[i].hw;
> > +                     ret = clk_cpy_name(parent->fw_name,
> > +                                        parent_data[i].fw_name, false);
> > +                     if (!ret)
> > +                             ret = clk_cpy_name(parent->name,
> > +                                                parent_data[i].name,
> > +                                                false);
> > +             } else if (parent_hws) {
> > +                     parent->hw = parent_hws[i];
> > +             } else {
> 
> Maybe there should also some kinda of check to verify if more than one option
> (among hws, parent_data and parent_names) was provided and throw a warn ?
> 
> Could be useful with drivers move away from parent_names ?

Same thing. It would be nice but we're sort of unable to do so unless we
do what I suggest above. Should we do it?


  reply	other threads:[~2019-03-15 17:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26 22:34 [PATCH v2 0/8] Rewrite clk parent handling Stephen Boyd
2019-02-26 22:34 ` [PATCH v2 1/8] clk: Combine __clk_get() and __clk_create_clk() Stephen Boyd
2019-02-26 22:34 ` [PATCH v2 2/8] clk: core: clarify the check for runtime PM Stephen Boyd
2019-02-26 22:34 ` [PATCH v2 3/8] clk: Introduce of_clk_get_hw_from_clkspec() Stephen Boyd
2019-02-26 22:34 ` [PATCH v2 4/8] clk: Inform the core about consumer devices Stephen Boyd
2019-02-26 22:34 ` [PATCH v2 5/8] clk: Move of_clk_*() APIs into clk.c from clkdev.c Stephen Boyd
2019-02-26 22:34 ` [PATCH v2 6/8] clk: Allow parents to be specified without string names Stephen Boyd
2019-03-02 18:40   ` Jerome Brunet
2019-03-06 18:00     ` Stephen Boyd
2019-03-02 21:25   ` Jeffrey Hugo
2019-03-06 17:48     ` Stephen Boyd
2019-03-06 21:45       ` Jeffrey Hugo
2019-03-15 10:01   ` Jerome Brunet
2019-03-15 17:16     ` Stephen Boyd [this message]
2019-03-19  9:25       ` Jerome Brunet
2019-02-26 22:34 ` [PATCH v2 7/8] clk: qcom: gcc-sdm845: Migrate to DT parent mapping Stephen Boyd
2019-02-26 22:34 ` [PATCH v2 8/8] arm64: dts: qcom: Specify XO clk as input to GCC node Stephen Boyd
2019-03-02  0:45 ` [PATCH v2 0/8] Rewrite clk parent handling Stephen Boyd

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=155267021941.20095.16439182841724325601@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=jhugo@codeaurora.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=miquel.raynal@bootlin.com \
    --cc=mturquette@baylibre.com \
    --cc=wens@csie.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).