On Thu, 2018-03-08 at 14:25 +0100, Lucas Stach wrote:
> This is unsafe, as the runtime PM callbacks are called from the PM
> workqueue, so this may deadlock when handling an i2c attached clock,
> which may already hold the clk_prepare mutex from another context.
>
> Signed-off-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
Reviewed-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>
regards
Philipp
> ---
> drivers/i2c/busses/i2c-imx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index c9632b2f0eaa..d7267dd9c7bf 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1226,7 +1226,7 @@ static int i2c_imx_runtime_suspend(struct device *dev)
> {
> struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
>
> - clk_disable_unprepare(i2c_imx->clk);
> + clk_disable(i2c_imx->clk);
>
> return 0;
> }
> @@ -1236,7 +1236,7 @@ static int i2c_imx_runtime_resume(struct device *dev)
> struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
> int ret;
>
> - ret = clk_prepare_enable(i2c_imx->clk);
> + ret = clk_enable(i2c_imx->clk);
> if (ret)
> dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);
>
