[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <TY1PR01MB1769B12A216ED3E76A40A6B7F5A90@TY1PR01MB1769.jpnprd01.prod.outlook.com>
Date: Thu, 6 Dec 2018 12:30:52 +0000
From: Phil Edworthy <phil.edworthy@...esas.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Russell King <linux@...linux.org.uk>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>,
"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v9 1/2] clk: Add comment about __of_clk_get_by_name()
error values
Hi Andy,
On 03 December 2018 13:31 Andy Shevchenko wrote:
> On Mon, Dec 03, 2018 at 11:13:08AM +0000, Phil Edworthy wrote:
> > It's not immediately obvious from the code that failure to get a clock
> > provider can return either -ENOENT or -EINVAL. Therefore, add a
> > comment to highlight this.
>
> > +/*
> > + * Beware the return values when np is valid, but no clock provider is
> found.
> > + * If name = NULL, the function returns -ENOENT.
> > + * If name != NULL, the function returns -EINVAL. This is because
> > +__of_clk_get()
>
> I would start new sentence from new line (this will emphasize the possible
> variants)
>
> * This is ...
I disagree, the explanation is specifically related to the case where the function
returns -EINVAL. Though this is a nit, so I'm not really bothered either way.
Thanks for the review!
Phil
> Otherwise looks good to me:
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
>
> > + * is called even if of_property_match_string() returns an error.
> > + */
> > static struct clk *__of_clk_get_by_name(struct device_node *np,
> > const char *dev_id,
> > const char *name)
> > --
> > 2.17.1
> >
>
> --
> With Best Regards,
> Andy Shevchenko
>
Powered by blists - more mailing lists