summaryrefslogtreecommitdiff
path: root/drivers/clk/versatile
diff options
context:
space:
mode:
authorHeiko Stuebner <heiko@sntech.de>2015-08-19 15:06:55 +0200
committerMichael Turquette <mturquette@baylibre.com>2015-08-24 16:49:15 -0700
commit10897370345b792c00ccba6aa7ea86ae6bfa2c7a (patch)
tree55a74d034e9fe791976ccf2d0f9a00dde649420a /drivers/clk/versatile
parent67c9a1b5dadf05e22d7e2d32604fb2b21bf3f666 (diff)
clk: rockchip: register pll mux before pll itself
The structure is xin24m -> pll -> pll-mux (xin24m,pll,xin32k). The pll does have an init callback to make sure the boot-selected frequency is using the expected pll settings and resets the same frequency using the values provided in the driver if necessary. The setting itself also involves remuxing the pll-mux temporarily to the xin24m source to let the new pll rate settle. Until now this worked flawlessly, even when it had the flaw of accessing the mux settings before the mux actually got registered. With the recent clock-core conversions this flaw became apparent in null pointer dereference in [<c03fc400>] (clk_hw_get_num_parents) from [<c0400df0>] (clk_mux_get_parent+0x14/0xc8) [<c0400ddc>] (clk_mux_get_parent) from [<c040246c>] (rockchip_rk3066_pll_set_rate+0xd8/0x320) So to fix that, simply register the pll-mux before the pll, so that it will be fully initialized when the pll clock executes its init- callback and possibly touches the pll-mux clock. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Michael Turquette <mturquette@baylibre.com>
Diffstat (limited to 'drivers/clk/versatile')
0 files changed, 0 insertions, 0 deletions