Hi Felipe, On Fri, Nov 08, 2013 at 12:00:48PM -0600, Felipe Balbi wrote: > From: Luciano Coelho > > Add a flag that indicate whether the clock is a crystal or not. > > Additionally, parse a new device tree binding in clk-fixed-rate to set > this flag. > > If clock-xtal isn't set, the clock framework will assume clock to be > generated by an oscillator. There's only one user for this binding > right now which is Texas Instruments' WiLink devices which need to know > details about the clock in order to initialize the underlying WiFi HW > correctly. > > Signed-off-by: Luciano Coelho > Signed-off-by: Felipe Balbi > --- > > Dropped CLK_IS_TYPE_DEFINED flag and just assume that if the flag > isn't there, default behavior will be taken. > > Documentation/devicetree/bindings/clock/fixed-clock.txt | 1 + > drivers/clk/clk-fixed-rate.c | 6 +++++- > include/linux/clk-provider.h | 1 + > 3 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.txt b/Documentation/devicetree/bindings/clock/fixed-clock.txt > index 0b1fe78..3036dfe 100644 > --- a/Documentation/devicetree/bindings/clock/fixed-clock.txt > +++ b/Documentation/devicetree/bindings/clock/fixed-clock.txt > @@ -12,6 +12,7 @@ Required properties: > Optional properties: > - gpios : From common gpio binding; gpio connection to clock enable pin. > - clock-output-names : From common clock binding. > +- clock-xtal: true when a clock is provided by a crystal > > Example: > clock { > diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c > index 1ed591a..5db9bf0 100644 > --- a/drivers/clk/clk-fixed-rate.c > +++ b/drivers/clk/clk-fixed-rate.c > @@ -91,13 +91,17 @@ void of_fixed_clk_setup(struct device_node *node) > struct clk *clk; > const char *clk_name = node->name; > u32 rate; > + unsigned long flags = CLK_IS_ROOT; > > if (of_property_read_u32(node, "clock-frequency", &rate)) > return; > > + if (of_property_read_bool(node, "clock-xtal")) > + flags |= CLK_IS_TYPE_XTAL; > + Introducing a new compatible instead of a property would make more sense here I think. Do you have a reason not to do so? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com