mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-30 19:51:31 -04:00
clk: clock multiplexers may register out of order
When a clock, C is initialised any orphan clocks listing C as
a possible parent are reparented to it regardless of the
parent requested by the orphan's get_parent() operation.
This means that multiplexers registered before their parents
are reparented to the first parent subsequently declared,
regardless of the selection made by the hardware registers.
For example:
static const char *sel[] = { "srcA", "srcB", "dummy", "srcC" };
child = clk_register_mux(NULL, "child", sel, ARRAY_SIZE(sel), ...);
clk_register_fixed(NULL, "dummy", ...);
clk_register_fixed(NULL, "srcA", ...);
clk_register_fixed(NULL, "srcB", ...);
clk_register_fixed(NULL, "srcC", ...);
Causes child's parent to always be "dummy".
To fix this, when an orphanned clock has a get_parent() operation,
only reparent to the clock indicated by get_parent().
Signed-off-by: Martin Fuzzey <[email protected]>
Signed-off-by: Mike Turquette <[email protected]>
[[email protected]: improve $SUBJECT]
This commit is contained in:
parent
45228ef322
commit
1f61e5f143
1 changed files with 9 additions and 1 deletions
|
|
@ -1298,12 +1298,20 @@ int __clk_init(struct device *dev, struct clk *clk)
|
|||
* walk the list of orphan clocks and reparent any that are children of
|
||||
* this clock
|
||||
*/
|
||||
hlist_for_each_entry_safe(orphan, tmp, tmp2, &clk_orphan_list, child_node)
|
||||
hlist_for_each_entry_safe(orphan, tmp, tmp2, &clk_orphan_list, child_node) {
|
||||
if (orphan->ops->get_parent) {
|
||||
i = orphan->ops->get_parent(orphan->hw);
|
||||
if (!strcmp(clk->name, orphan->parent_names[i]))
|
||||
__clk_reparent(orphan, clk);
|
||||
continue;
|
||||
}
|
||||
|
||||
for (i = 0; i < orphan->num_parents; i++)
|
||||
if (!strcmp(clk->name, orphan->parent_names[i])) {
|
||||
__clk_reparent(orphan, clk);
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
/*
|
||||
* optional platform-specific magic
|
||||
|
|
|
|||
Loading…
Reference in a new issue