linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: linux-gpio@vger.kernel.org,
	Michael Turquette <mturquette@baylibre.com>,
	linux-clk@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] clk: let of_clk_get_parent_name() fail for invalid clock-indices
Date: Tue, 1 Dec 2015 00:40:48 -0800	[thread overview]
Message-ID: <20151201084048.GC26865@codeaurora.org> (raw)
In-Reply-To: <CAK7LNAT5Q+MVj8KvT_WMwtAFhFN5Q6yXk6vY9oNpoBtEBs-C6Q@mail.gmail.com>

On 12/01, Masahiro Yamada wrote:
> 2015-12-01 9:58 GMT+09:00 Stephen Boyd <sboyd@codeaurora.org>:
> > Here's the proposed alternative, if you agree I will merge it
> > with the above commit text and attribution to you.
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index a66efc9d8bfc..f54583a9835a 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -3079,6 +3079,9 @@ const char *of_clk_get_parent_name(struct device_node *np, int index)
> >                 }
> >                 count++;
> >         }
> > +       /* We went off the end of 'clock-indices' without finding it */
> > +       if (!vp && count)
> > +               return NULL;
> >
> >         if (of_property_read_string_index(clkspec.np, "clock-output-names",
> >                                           index,
> >
> 
> No, again.
> The existence of "clock-indices" should be checked
> in order to omit the zero-length "clock-indices".
> 

Ah I missed that one. All these corner cases for broken DTs. Too
bad we don't have that DT validator.

> 
> OK, let me guess the next alternative from you.
> 
> 
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -3079,6 +3079,9 @@ const char *of_clk_get_parent_name(struct device_node *np, int index)
> >                 }
> >                 count++;
> >         }
> > +       /* We went off the end of 'clock-indices' without finding it */
> > +       if (prop && !vp)
> > +               return NULL;
> >
> >         if (of_property_read_string_index(clkspec.np, "clock-output-names",
> >                                           index,
> >

Cool, we can go faster now.

> 
> This works, but clumsy things are:
> 
> [1] If the "clock-indices" is missing, we can know it
>      before looping around the of_property_for_each_u32().
>      Checking the "prop" after the loop seems odd.

The of_property_for_each_u32 macro will do pretty much the same
work that you've done in your patch. So we're not going to go
around the loop at all in this case, we're just going to get the
property like you've done, and then of_prop_next_u32() is going
to return NULL and we'll never enter the loop.

Checking the property again is sort of odd, but we do similar
sorts of checks at the end of loops in other places in the
kernel, so it isn't out of the ordinary.

> 
> [2] "prop" and "vp" seem to be temporary storage that we should not
>      know what they exactly are, like the auxiliary pointer in
> list_for_each_safe().

True. In those cases, we check for list emptiness before
iterating over it with the list helper macros. So it sounds like
we should do that here as well.

> 
> 
> Why do you insist on of_property_for_each_u32()?
> It no longer fits in here.
> 

Sure. The other problem is be32_to_cpup() usage. I'd rather that
we use the style of looping that of_property_for_each_u32 does.
It doesn't make any assumptions about how the data is in memory.
Instead we call the iterator function and it gets the next value.

So here's another try, that open codes the macro so we can add
our count inside and check for a boolean property without
duplication.

----8<----

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a66efc9d8bfc..a2112cdab191 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3059,6 +3059,7 @@ const char *of_clk_get_parent_name(struct device_node *np, int index)
 	u32 pv;
 	int rc;
 	int count;
+	int len;
 	struct clk *clk;
 
 	rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index,
@@ -3067,18 +3068,24 @@ const char *of_clk_get_parent_name(struct device_node *np, int index)
 		return NULL;
 
 	index = clkspec.args_count ? clkspec.args[0] : 0;
-	count = 0;
+	len = 0;
 
-	/* if there is an indices property, use it to transfer the index
+	/*
+	 * if there is an indices property, use it to transfer the index
 	 * specified into an array offset for the clock-output-names property.
 	 */
-	of_property_for_each_u32(clkspec.np, "clock-indices", prop, vp, pv) {
+	prop = of_find_property(clkspec.np, "clock-indices", &len);
+	for (vp = of_prop_next_u32(prop, NULL, &pv), count = 0;
+	     vp;
+	     vp = of_prop_next_u32(prop, vp, &pv), count++) {
 		if (index == pv) {
 			index = count;
 			break;
 		}
-		count++;
 	}
+	/* We went off the end of 'clock-indices' without finding it */
+	if (prop && count == len / sizeof(u32))
+		return NULL;
 
 	if (of_property_read_string_index(clkspec.np, "clock-output-names",
 					  index,
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2015-12-01  8:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-30  8:46 [PATCH v2] clk: let of_clk_get_parent_name() fail for invalid clock-indices Masahiro Yamada
2015-11-30  8:48 ` Masahiro Yamada
2015-12-01  0:58 ` Stephen Boyd
2015-12-01  2:48   ` Masahiro Yamada
2015-12-01  8:40     ` Stephen Boyd [this message]
2015-12-03  2:25       ` Masahiro Yamada

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=20151201084048.GC26865@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=yamada.masahiro@socionext.com \
    /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).