Heiko,
On Fri, Jan 16, 2015 at 8:52 AM, Heiko St?bner <heiko at sntech.de> wrote:
> Lockdep reported a possible deadlock between the cpuclk lock and for example
> the i2c driver.
>
> CPU0 CPU1
> ---- ----
> lock(clk_lock);
> local_irq_disable();
> lock(&(&i2c->lock)->rlock);
> lock(clk_lock);
> <Interrupt>
> lock(&(&i2c->lock)->rlock);
>
> *** DEADLOCK ***
>
> The generic clock-types of the core ccf already use spin_lock_irqsave when
> touching clock registers, so do the same for the cpuclk.
>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
> drivers/clk/rockchip/clk-cpu.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/rockchip/clk-cpu.c b/drivers/clk/rockchip/clk-cpu.c
> index 75c8c45..3ecdf7d 100644
> --- a/drivers/clk/rockchip/clk-cpu.c
> +++ b/drivers/clk/rockchip/clk-cpu.c
> @@ -124,10 +124,11 @@ static int rockchip_cpuclk_pre_rate_change(struct rockchip_cpuclk *cpuclk,
> {
> const struct rockchip_cpuclk_reg_data *reg_data = cpuclk->reg_data;
> unsigned long alt_prate, alt_div;
> + unsigned long flags = 0;
nit: I don't often see flags initted to 0 here when using
spin_lock_irqsave(). I don't think it's needed...
I doubt it really matters though, and this looks fine to me.
Reviewed-by: Doug Anderson <dianders at chromium.org>
-Doug
