Re: [PATCH] i2c: jz4780: Cache clock rate at probe to prevent CCF prepare_lock deadlock

Hi Nikolaus,

On Fri, Jul 10, 2026 at 08:58:35AM +0200, H. Nikolaus Schaller wrote:
> Fix a severe AB/BA deadlock between the Common Clock Framework (CCF)
> and the I2C adapter lock, which triggers when an I2C-controlled clock
> generator (like the Si5351) is registered or modified under the CCF.
> 
> During a clock frequency change, the CCF acquires its global 'prepare_lock'
> mutex and calls i2c_transfer() to update the chip registers, stalling
> for the adapter's I2C bus lock.

I don't think caching the clock rate once at probe is safe.

If the controller clock rate changes afterwards,
jz4780_i2c_set_speed() will keep using the stale cached value and
calculate incorrect bus timings.

Andi

> Concurrently, a parallel transfer on the same bus (e.g., a GPIO expander
> handling LEDs) can hold the I2C adapter lock. Inside the transfer path,
> jz4780_i2c_set_speed() calls clk_get_rate() to dynamically calculate
> timings. This call attempts to acquire the blocked CCF 'prepare_lock',
> creating a circular dependency that freezes the system or at least
> the involved processes and workers.
> 
> Eliminate the synchronous clk_get_rate() call from the active transfer
> path by caching the peripheral clock rate once - inside the private
> jz4780_i2c structure during jz4780_i2c_probe(). Update
> jz4780_i2c_set_speed() to use this cached value, decoupling active I2C
> transactions from the CCF internal locks.
> 
> Assisted-by web based Google AI.
> 
> Fixes: ba92222ed63a12 ("i2c: jz4780: Add i2c bus controller driver for Ingenic JZ4780")
> Cc: [email protected]
> Signed-off-by: H. Nikolaus Schaller <[email protected]>