linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] clk: tegra: make tegra_clocks_apply_init_table arch_initcall
Date: Mon, 21 Jul 2014 23:55:25 +0200	[thread overview]
Message-ID: <20140721215523.GE12076@mithrandir> (raw)
In-Reply-To: <53CD896C.3030605@wwwdotorg.org>

On Mon, Jul 21, 2014 at 03:43:08PM -0600, Stephen Warren wrote:
> On 07/16/2014 02:27 AM, Peter De Schrijver wrote:
> > On Wed, Jul 16, 2014 at 09:19:33AM +0200, Thierry Reding wrote:
> >> * PGP Signed by an unknown key
> >>
> >> On Tue, Jul 15, 2014 at 06:24:32PM +0300, Peter De Schrijver wrote:
> >> [...]
> >>> diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
> >>> index d081732..65cde4e 100644
> >>> --- a/drivers/clk/tegra/clk.c
> >>> +++ b/drivers/clk/tegra/clk.c
> >>> @@ -290,10 +290,13 @@ struct clk ** __init tegra_lookup_dt_id(int clk_id,
> >>>  
> >>>  tegra_clk_apply_init_table_func tegra_clk_apply_init_table;
> >>>  
> >>> -void __init tegra_clocks_apply_init_table(void)
> >>> +static int __init tegra_clocks_apply_init_table(void)
> >>>  {
> >>>  	if (!tegra_clk_apply_init_table)
> >>> -		return;
> >>> +		return 0;
> >>
> >> Shouldn't this be an error? Or perhaps WARN()? To make sure this gets
> > 
> > An arch_initcall will be called for every ARM platform I think? In case
> > this gets called on a non-Tegra platform, tegra_clk_apply_init_table will not
> > be set and therefore a silent return 0; seems the most appropriate thing to do
> > to me?
> 
> This is one reason that doing all the initialization from separate
> initcalls sucks. Much better to have a single top-level initialization
> function that calls exactly what is needed, only what is needed, and
> only runs on the correct SoCs.
> 
> But failing that, I guess you need to say something like
> of_is_compatible(root node, "nvidia Tegra"), but of course the
> definition of "nvidia Tegra" is an ever-growing list of possible values
> that needs to be used from each separate initcall...

FWIW, we have soc_is_tegra() now in include/soc/tegra/common.h which is
meant to be used for exactly this purpose. I agree that it isn't optimal
but it's pretty good. It should be easy to refactor this to make it
callable from a top-level initialization function when a decision
regarding that has been made.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/07496a14/attachment.sig>

  reply	other threads:[~2014-07-21 21:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15 15:24 [PATCH 0/6] clock support for Tegra132 Peter De Schrijver
2014-07-15 15:24 ` [PATCH 1/6] clk: tegra: don't abort clk init on error Peter De Schrijver
2014-07-16  7:20   ` Thierry Reding
2014-07-22 17:16   ` Stephen Warren
2014-08-15 22:45     ` Peter De Schrijver
2014-07-15 15:24 ` [PATCH 2/6] clk: tegra: make tegra_clocks_apply_init_table arch_initcall Peter De Schrijver
2014-07-16  7:19   ` Thierry Reding
2014-07-16  8:27     ` Peter De Schrijver
2014-07-21 21:43       ` Stephen Warren
2014-07-21 21:55         ` Thierry Reding [this message]
2014-07-22 17:15   ` Stephen Warren
2014-07-15 15:24 ` [PATCH 3/6] clk: tegra: Update binding doc Tegra132 Peter De Schrijver
2014-07-16  7:25   ` Thierry Reding
2014-07-16  8:42     ` Peter De Schrijver
2014-07-15 15:24 ` [PATCH 4/6] clk: tegra: add nvidia,tegra132-ccplex-clk binding Peter De Schrijver
2014-07-16  7:32   ` Thierry Reding
2014-07-22 17:18   ` Stephen Warren
2014-07-15 15:24 ` [PATCH 5/6] clk: tegra: Add support for Tegra132 CAR clocks Peter De Schrijver
2014-07-16  7:44   ` Thierry Reding
2014-07-16  8:41     ` Peter De Schrijver
2014-07-15 15:24 ` [PATCH 6/6] clk: tegra: Add Tegra132 ccplex clocks Peter De Schrijver
2014-07-15 20:35   ` Rhyland Klein
2014-07-15 20:40     ` Rhyland Klein
2014-07-16  8:30       ` Peter De Schrijver
2014-07-16  8:31     ` Peter De Schrijver

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=20140721215523.GE12076@mithrandir \
    --to=thierry.reding@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).