[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <155742263550.14659.13420287678025539904@swboyd.mtv.corp.google.com>
Date: Thu, 09 May 2019 10:23:55 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: "Ardelean, Alexandru" <alexandru.Ardelean@...log.com>,
"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc: "heiko@...ech.de" <heiko@...ech.de>,
"andriy.shevchenko@...ux.intel.com"
<andriy.shevchenko@...ux.intel.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 02/16] treewide: rename match_string() -> __match_string()
Quoting Ardelean, Alexandru (2019-05-09 01:52:53)
> On Wed, 2019-05-08 at 10:00 -0700, Stephen Boyd wrote:
> > [External]
> >
> >
> > (Trimming the lists but keeping lkml)
> >
> > Quoting Alexandru Ardelean (2019-05-08 04:28:28)
> > > This change does a rename of match_string() -> __match_string().
> > >
> > > There are a few parts to the intention here (with this change):
> > > 1. Align with sysfs_match_string()/__sysfs_match_string()
> > > 2. This helps to group users of `match_string()` into simple users:
> > > a. those that use ARRAY_SIZE(_a) to specify the number of elements
> > > b. those that use -1 to pass a NULL terminated array of strings
> > > c. special users, which (after eliminating 1 & 2) are not that many
> > > 3. The final intent is to fix match_string()/__match_string() which is
> > > slightly broken, in the sense that passing -1 or a positive value
> > > does
> > > not make any difference: the iteration will stop at the first NULL
> > > element.
> > >
> > > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@...log.com>
> > > ---
> >
> > [...]
> > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > index 96053a96fe2f..0b6c3d300411 100644
> > > --- a/drivers/clk/clk.c
> > > +++ b/drivers/clk/clk.c
> > > @@ -2305,8 +2305,8 @@ bool clk_has_parent(struct clk *clk, struct clk
> > > *parent)
> > > if (core->parent == parent_core)
> > > return true;
> > >
> > > - return match_string(core->parent_names, core->num_parents,
> > > - parent_core->name) >= 0;
> > > + return __match_string(core->parent_names, core->num_parents,
> > > + parent_core->name) >= 0;
> >
> > This is essentially ARRAY_SIZE(core->parent_names) so it should be fine
> > to put this back to match_string() later in the series.
>
> I don't think so.
> core->parents & core->parent_names seem to be dynamically allocated array.
> ARRAY_SIZE() is a macro that expands at pre-compile time and evaluates
> correctly at compile time only for static arrays.
>
Ah ok. The ARRAY_SIZE() is done inside the match_string() function? I
missed that.
Powered by blists - more mailing lists