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

[Andi Shyti]

On Thu, Jul 16, 2026 at 07:44:20AM +0200, H. Nikolaus Schaller wrote:
> Hi Andi,
> 
> > Am 16.07.2026 um 00:07 schrieb Andi Shyti <andi.shyti@xxxxxxxxxx>:
> > 
> > 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.
> 
> Ok, valid point to discuss.
> 
> 
> > If the controller clock rate changes afterwards,
> > jz4780_i2c_set_speed() will keep using the stale cached value and
> > calculate incorrect bus timings.
> 
> But: is clock rate ever changed during operation? Usually it is defined
> by the device tree constant.

That's what you are saying in your commit message.

Andi