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

[H. Nikolaus Schaller]

Hi Andi,

> Am 16.07.2026 um 13:41 schrieb Andi Shyti <andi.shyti@xxxxxxxxxx>:
> 
> On Thu, Jul 16, 2026 at 10:33:56AM +0200, H. Nikolaus Schaller wrote:
>>> 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:
>>>>> Am 16.07.2026 um 00:07 schrieb Andi Shyti <andi.shyti@xxxxxxxxxx>:
>>>>> 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.
> 
> If you make a claim in the commit message, I expect the code to
> support it.

I still do not see where you read the claim you criticize.

The commit messages says:

> 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.

This clearly says that the clock generator is I2C controlled.

And that the problem arises if the frequency *of the clock generator* is changed.

It does not say anything about *changing the I2C bus clock* itself.

> 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.

This describes what happens in the current code:
- someone wants to change the clock frequency of the Si5321
- this acquires the CCF lock for this change
- the driver tries to read/write some registers from the i2c chip
- for this it does some I2C transfer
- which locks the I2C bus
- the jz4780 driver tries to read the I2C frequency in its I2C bus driver
- and the system (including I2C) hangs

What is not clear here?

The patch fixes this by caching the i2c clock rate and avoiding that
an i2c transfer asks the CCF for anything.

> 
> You say that the clock rate can change, but then you store it
> only once at probe time. That immediately suggests that later
> rate changes will be ignored by the transfer path.

Where does the commit message say that the *I2C clock rate* is changed
or can change?

It can't be changed by standard API and therefore its clock rate can be
cached as proposed during probe of the jz4780 bus driver.

> 
>> But again: how would you solve this?
> 
> It's not my role to give you a solution. I'm just commenting on
> what I see.

If you can comment, I simply expect you to have experience to give
a hint how to solve it differently.

> Besides that, is that an issue you have encountered yourself? Is
> it a frequent issue?

Yes. It comes 100% if you connect an Si5351 to the CI20 board or
others board which use the same driver (e.g. some X1600 based one).

It is likely that any other i2c connected device which registers some
clocks is running into the same problem.

Therefore I consider this as a fundamental design flaw which is solved
by this patch.

BR and thanks,
Nikolaus