All of lore.kernel.org
 help / color / mirror / Atom feed
From: mfuzzey@parkeon.com (Martin Fuzzey)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2] ARM: i.MX5: Allow DT clock providers
Date: Thu, 18 Apr 2013 10:36:53 +0200	[thread overview]
Message-ID: <516FB0A5.9050903@parkeon.com> (raw)
In-Reply-To: <20130418063056.GA20566@S2101-09.ap.freescale.net>

On 18/04/13 08:30, Shawn Guo wrote:
> +static struct clk * __init mx5_obtain_fixed_clock_from_dt(const char *name)
> +{
> +#ifdef CONFIG_OF
> We have selected USE_OF at the sub-architecture level, so the ifdef
> plays nothing here.
Ah ok so what happens on non DT platforms (looks like Babbage)
Does this mean that there is an empty DT in that case?

I was going by the existing code which already has this #ifdef

>> +	struct of_phandle_args phandle = {0};
>> +	struct clk *clk = ERR_PTR(-ENODEV);
>> +	char *compatible;
>> +
>> +	compatible = kasprintf(GFP_KERNEL, "fsl,imx-%s", name);
> What about finding the node by path as below?
>
> 	path = kasprintf(GFP_KERNEL, "/clocks/%s", name);
> 	phandle.np = of_find_node_by_path(path);
>
> I have to admit that those imx custom compatibles for fixed-clock
> shouldn't necessarily be there at all.  Let's stop spreading the use.
I can't find anything in the DT binding documentation that says the 
clocks have to be
under /clocks  (but then again the fsl,imx- compatible string isn't 
documented either).

My understanding of DT is that the absolute node path is generally 
unimportant with
the exception of a few special nodes like /, /memory, /chosen

But I don't have a strong opinion on this - if the consensus is that 
path based lookup
is better I'll do that.

Regards,

Martin

  reply	other threads:[~2013-04-18  8:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-15  8:07 [PATCH V2] ARM: i.MX5: Allow DT clock providers Martin Fuzzey
2013-04-18  6:30 ` Shawn Guo
2013-04-18  8:36   ` Martin Fuzzey [this message]
2013-04-18 15:15     ` Shawn Guo

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=516FB0A5.9050903@parkeon.com \
    --to=mfuzzey@parkeon.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.