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
next prev parent 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.