On Mon, Sep 30, 2024 at 09:27:41PM GMT, Marek Vasut wrote:
> In case there is any sort of clock controller attached to this I2C bus
> controller, for example Versaclock or even an AIC32x4 I2C codec, then
> an I2C transfer triggered from the clock controller clk_ops .prepare
> callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.
>
> This is because the clock controller first grabs the prepare_lock mutex
> and then performs the prepare operation, including its I2C access. The
> I2C access resumes this I2C bus controller via .runtime_resume callback,
> which calls clk_prepare_enable(), which attempts to grab the prepare_lock
> mutex again and deadlocks.
>
> Since the clock are already prepared since probe() and unprepared in
> remove(), use simple clk_enable()/clk_disable() calls to enable and
> disable the clock on runtime suspend and resume, to avoid hitting the
> prepare_lock mutex.
>
> Acked-by: Alain Volmat <alain.volmat@xxxxxxxxxxx>
> Signed-off-by: Marek Vasut <marex@xxxxxxx>
I think we also need:
Fixes: 4e7bca6fc07b ("i2c: i2c-stm32f7: add PM Runtime support")
Cc: <stable@xxxxxxxxxxxxxxx> # v5.0+
I'm adding them, please, let me know if you think they are not
needed.
For now I merged this patch in i2c/i2c-host-fixes.
Thanks,
Andi
