linux-mips
[Top] [All Lists]

Re: [RFC] MIPS: BCM63XX: switch to common clock and Device Tree

To: Jonas Gorski <jonas.gorski@gmail.com>
Subject: Re: [RFC] MIPS: BCM63XX: switch to common clock and Device Tree
From: Stephen Warren <swarren@wwwdotorg.org>
Date: Mon, 12 Nov 2012 22:04:36 -0700
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>, John Crispin <blogic@openwrt.org>, Maxime Bizon <mbizon@freebox.fr>, Florian Fainelli <florian@openwrt.org>, Kevin Cernekee <cernekee@gmail.com>, devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-reply-to: <1352638249-29298-11-git-send-email-jonas.gorski@gmail.com>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
References: <1352638249-29298-1-git-send-email-jonas.gorski@gmail.com> <1352638249-29298-11-git-send-email-jonas.gorski@gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
On 11/11/2012 05:50 AM, Jonas Gorski wrote:
> Switch BCM63XX to the common clock framework and use clkdev for
> providing clock name lookups for non-DT devices.
> 
> Clocks can have a frequency and gate-bit, or none, in case they
> are just provided for drivers expecting them to be present.

> diff --git a/Documentation/devicetree/bindings/clock/bcm63xx-clock.txt 
> b/Documentation/devicetree/bindings/clock/bcm63xx-clock.txt

A very minor nit, but it might be nice to add the DT binding
documentation before (or as part of) the patches that use them (code
that parses them, or using the bindings in .dts files)

Of course, I'm relying on my email receive order, to judge this since
the patch numbering didn't come through, so perhaps the patches are
already set up this way...

<Prev in Thread] Current Thread [Next in Thread>