[PATCH v5] clk: add MOXA ART SoCs clock driver

Quoting Tomasz Figa (2013-07-23 01:09:06)

On Monday 22 of July 2013 10:21:38 Mark Rutland wrote:

quoted

On Fri, Jul 19, 2013 at 09:17:17AM +0100, Jonas Jensen wrote:

quoted

This patch adds MOXA ART SoCs clock driver support.

Signed-off-by: Jonas Jensen <redacted>
---

Notes:
    Changes since v4:
    
    1. remove unnecessary header includes
    
    Applies to next-20130716
 
 .../bindings/clock/moxa,moxart-core-clock.txt      | 23 ++++++++
 drivers/clk/Makefile                               |  1 +
 drivers/clk/clk-moxart.c                           | 69
 ++++++++++++++++++++++ 3 files changed, 93 insertions(+)
 create mode 100644
 Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
 create mode 100644 drivers/clk/clk-moxart.c

diff --git
a/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
new file mode 100644
index 0000000..528c8b0

--- /dev/null
+++

b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt

@@ -0,0 +1,23 @@
+Device Tree Clock bindings for arch-moxart
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+MOXA ART SoCs allow to determine core clock frequencies by reading
+a register.
+
+Required properties:
+- compatible : Should be "moxa,moxart-core-clock"
+- #clock-cells : Should be 0
+- reg : Should contain registers location and length
+- clock-output-names : Should be "coreclk"
+
+For example:
+
+   coreclk: core-clock at 98100000 {
+           compatible = "moxa,moxart-core-clock";
+           #clock-cells = <0>;
+           reg = <0x98100000 0x34>;
+           clock-output-names = "coreclk";
+   };

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..933622f 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile

@@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)  += clk-composite.o

 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o

+obj-$(CONFIG_ARCH_MOXART)  += clk-moxart.o

 obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
 obj-$(CONFIG_ARCH_HIGHBANK)        += clk-highbank.o
 obj-$(CONFIG_ARCH_NSPIRE)  += clk-nspire.o

diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
new file mode 100644
index 0000000..5559371
--- /dev/null
+++ b/drivers/clk/clk-moxart.c

@@ -0,0 +1,69 @@
+/*
+ * MOXA ART SoCs clock driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen@gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/clkdev.h>
+
+void __init moxart_of_clk_init(struct device_node *node)
+{
+   static void __iomem *base;
+   struct clk *clk;
+   unsigned long rate;
+   unsigned int mul, val, div;
+   const char *name;
+
+   base = of_iomap(node, 0);
+   if (IS_ERR(base))
+           panic("%s: of_iomap failed\n", node->full_name);

As far as I'm aware, of_iomap returns NULL, not an ERR_PTR value.

Also, is it necessary to panic() ? In v1 of the patch you used pr_err...

This is a good question in general, not only for this driver.

IMHO if you know early that something is really wrong, to the point that 
the system won't be able to work normally (and failing to initialize 
clocks looks like it) it is better to let the user/developer know that 
something is utterly wrong at this point without letting the system run 
for a bit more and fail anyway with a harder to track down error message.

You can let the user/developer know that something is utterly wrong with
a WARN.

Where panics and BUGs come back to haunt you is when you are bringing up
a new platform or SoC that uses this clock driver, but this clock driver
fails pending some subtle change for the new platform/SoC.

But perhaps your bootloader at least set the clocks up for you sensibly
and your other device drivers might bail out due to not having clocks
but at least you could boot your new system.  But putting a panic/BUG
here makes the above scenario impossible.

It's not so obvious, though, what kinds of failure should be considered 
critical. IMHO any failure in low level initialization code, but this is 
debatable, I guess.

Agreed that's it's hard to know when to use them. But if you can get
away with a WARN then I always err on the cautious side and try to
prevent panicing the system explicitly.

Regards,
Mike

Best regards,
Tomasz