RE: [PATCH] clk: clk-fixed-factor: Use new macro CLK_OF_DECLARE_DRIVER

From: Stephen Boyd
Date: Thu Mar 15 2018 - 14:47:19 EST


Quoting Rajan Vaja (2018-03-09 11:27:40)
> > From: Stephen Boyd [mailto:sboyd@xxxxxxxxxx]
> >
> > Is the intent to register the clk twice? I believe things are working as
> > intended without this patch, so maybe you can explain a little more what
> > you're trying to fix.
> [Rajan] Yes. During of_clk_init() if some DT fixed factor clock has
> parent which is neither mentioned in output-clock-names of clock
> controller nor registered as clock provider, of_clk_init() will try to
> forcefully register in second loop.
>
> if (force || parent_ready(clk_provider->np)) {
>
> /* Don't populate platform devices */
> of_node_set_flag(clk_provider->np,
> OF_POPULATED);
>
> So registration of this DT fixed-factor clock would fail as parent
> would be NULL as below (called from _of_fixed_factor_clk_setup()):
> parent_name = of_clk_get_parent_name(node, 0);
>
> On the other hand, even if registration failed, that node will be
> marked as OF_POPULATED, so probe of clk-fixed-factor.c will also not
> be called and that DT fixed-factor clock would never be registered.
>
> Same thing is discussed at https://lkml.org/lkml/2017/6/5/681 .

Ok. I believe the answer is to fix the DT to describe the parent chain
properly with clock-output-names. Otherwise, we have no good way of
figuring out what the name should be.

The alternative is to start working on a solution for having the clk
framework stop using strings to describe clk topology. My plan there is
to allow clk registration to indicate that another parent names array
should be used with clk_get() of the device or node pointer that's
associated with the clk during registration to find the parent . If we
had that, then we could hook up clks into the tree by calling clk_get()
in the framework and map through the clock-names property. This also
gets us to a point where clk names don't have to be globally unique,
which would be nice.