Dead lock with clock global prepare_lock mutex and device's power.runtime_status

[Peng Fan]

+Ulf

On Tue, Jul 01, 2025 at 03:16:08AM +0000, Carlos Song wrote:
>Hi, All:
>
>We met the dead lock issue recently and think it should be common issue and not sure how to fix it.
>
>We use gpio-gate-clock clock provider (drivers/clk/clk-gpio.c), gpio is one of i2c gpio expander (drivers/gpio/gpio-pcf857x.c). Our i2c driver enable run time pm (drivers/i2c/busses/i2c-imx-lpi2c.c [1]). System random blocked when at reboot.
>
>The dead lock happen as below call stacks
>
>Task 117                                                Task 120
>
>schedule()
>clk_prepare_lock()--> wait prepare_lock(mutex_lock)     schedule() wait for power.runtime_status exit RPM_SUSPENDING
>                           ^^^^ A                       ^^^^ B
>clk_bulk_unprepare()                                    rpm_resume()
>lpi2c_runtime_suspend()                                 pm_runtime_resume_and_get()
>...                                                     lpi2c_imx_xfer()
>                                                        ...
>rpm_suspend() set RPM_SUSPENDING                        pcf857x_set();
>                           ^^^^ B                       ...
>                                                        clk_prepare_lock() --> hold prepare_lock
>                                                        ^^^^ A
>                                                        ...
>

This is a common issue that clk use a big prepare lock which is easy
to trigger dead lock with runtime pm. I recalled that pengutronix raised
this, but could not find the information.

In this case, there are two clock providers that are independent.
So I think using one global prepare lock does not make sense here.

Stephen, 
 I propose using a per provider prepare lock if the providers are
 totally independent. How do you think?

Thanks,
Peng