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

[H. Nikolaus Schaller]

> Am 16.07.2026 um 09:43 schrieb Andi Shyti <andi.shyti@xxxxxxxxxx>:
> 
> 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.

The Si5351 clock generator driver is connected through this i2c bus. And that
is referred to by "when an I2C-controlled clock generator (like the Si5351) is 
registered or modified under the CCF".

Only then, this bug faces surface. Because that driver changes it's clock through
sending i2c commands which also ask for the lock.

But again: how would you solve this?

BR and thanks,
Nikolaus