linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Return checks for clock calls
@ 2018-03-23  9:49 Abel Vesa
  2018-03-24  0:27 ` Fabio Estevam
  0 siblings, 1 reply; 2+ messages in thread
From: Abel Vesa @ 2018-03-23  9:49 UTC (permalink / raw)
  To: festevam, shawnguo
  Cc: Anson Huang, Leonard Crestez, Daniel Baluta, Adriana Reus,
	Fabio Estevam, dl-linux-imx, linux-kernel, linux-arm-kernel,
	linux-clk, abelvesa

Hi Shawn, Fabio,

I'm trying to get the imx clks changes upstreamed. To that end, I reached this
old commit that adds some wrappers over the generic clk API. Here is the commit
message:

	ARM: imx6: add return check for clock calls

	There are a bunch of clk_enable_prepare, clk_set_parent and clk_set_rate
	calls in imx6 clock driver's initialization.  They are called without
	retunr check.  If there is something going wrong with the calls, they
	will just fail silently.

	The patch creates a set of helper functions imx_clk_enable_prepare,
	imx_clk_set_parent and imx_clk_set_rate, and use them instead from clock
	initialization to check the return and print error message to tell
	failures if any.

	Signed-off-by: Shawn Guo <shawn.guo@freescale.com>

And it adds the imx_clk_set_parent, imx_clk_prepare_enable and
imx_clk_set_rate which basically just print an error message if the generic
functions have failed.

The only plus of these wrappers is that we at least see that the generic
functions have failed, but the behaviour is not changed in any way.

Question is, do we want this upstreamed considering that we need to replace the
calls throughout all the older imx socs ?

Abel

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Return checks for clock calls
  2018-03-23  9:49 Return checks for clock calls Abel Vesa
@ 2018-03-24  0:27 ` Fabio Estevam
  0 siblings, 0 replies; 2+ messages in thread
From: Fabio Estevam @ 2018-03-24  0:27 UTC (permalink / raw)
  To: Abel Vesa
  Cc: shawnguo, Anson Huang, Leonard Crestez, Daniel Baluta,
	Adriana Reus, Fabio Estevam, dl-linux-imx, linux-kernel,
	linux-arm-kernel, linux-clk, abelvesa

Hi Abel,

On Fri, Mar 23, 2018 at 6:49 AM, Abel Vesa <abel.vesa@nxp.com> wrote:
> Hi Shawn, Fabio,
>
> I'm trying to get the imx clks changes upstreamed. To that end, I reached this
> old commit that adds some wrappers over the generic clk API. Here is the commit
> message:
>
>         ARM: imx6: add return check for clock calls
>
>         There are a bunch of clk_enable_prepare, clk_set_parent and clk_set_rate
>         calls in imx6 clock driver's initialization.  They are called without
>         retunr check.  If there is something going wrong with the calls, they
>         will just fail silently.
>
>         The patch creates a set of helper functions imx_clk_enable_prepare,
>         imx_clk_set_parent and imx_clk_set_rate, and use them instead from clock
>         initialization to check the return and print error message to tell
>         failures if any.
>
>         Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
>
> And it adds the imx_clk_set_parent, imx_clk_prepare_enable and
> imx_clk_set_rate which basically just print an error message if the generic
> functions have failed.
>
> The only plus of these wrappers is that we at least see that the generic
> functions have failed, but the behaviour is not changed in any way.
>
> Question is, do we want this upstreamed considering that we need to replace the
> calls throughout all the older imx socs ?

IMHO we should not introduce these new helper functions.

We can simply explicitly check for errors with the existing clock
functions when needed.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-03-24  0:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-23  9:49 Return checks for clock calls Abel Vesa
2018-03-24  0:27 ` Fabio Estevam

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).