[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1442535513.19102.83.camel@freescale.com>
Date: Thu, 17 Sep 2015 19:18:33 -0500
From: Scott Wood <scottwood@...escale.com>
To: Stephen Boyd <sboyd@...eaurora.org>
CC: Mike Turquette <mturquette@...libre.com>,
<linux-kernel@...r.kernel.org>, <linux-clk@...r.kernel.org>,
Boris Brezillon <boris.brezillon@...e-electrons.com>,
Chao Xie <chao.xie@...vell.com>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
Tomasz Figa <tomasz.figa@...il.com>,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
Emilio López <emilio@...pez.com.ar>,
Tero Kristo <t-kristo@...com>,
Geert Uytterhoeven <geert+renesas@...der.be>
Subject: Re: [PATCH 02/26] clk: Replace __clk_get_num_parents with
clk_hw_get_num_parents()
On Fri, 2015-07-31 at 10:03 -0700, Stephen Boyd wrote:
> Mostly converted with the following semantic patch:
>
> @@
> struct clk_hw *E;
> @@
>
> -__clk_get_num_parents(E->clk)
> +clk_hw_get_num_parents(E)
I don't understand why this is considered a clock provider API. How is a
clock consumer, such as cpufreq, supposed to find out the number of parents
or similar information, so that it knows what its options are for calling
clk_set_parent()?
This is the caller I had in mind:
http://patchwork.ozlabs.org/patch/507619/
Surely asking the clock to describe itself is better than what that cpufreq
driver currently does, which is to look in the device tree and make
assumptions about how that maps to what the clock provider driver does...
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists