Re: [PATCH] i2c: qcom-geni: restore tSCL with 32MHz I2C fast-mode

[Thorsten Leemhuis]

On 10/13/26 20:28, Mukesh Savaliya wrote:
> On 10/13/2026 1:04 PM, Thorsten Leemhuis wrote:
>> On 10/9/26 21:01, Sasha Levin wrote:
>>>> On 9/30/2026 3:01 PM, Daniel J Blueman wrote:
>>>>> I would revert the original patch if there is hardware that uses the
>>>>> I2C 1MHz fast-mode, since the current timings aren't to spec, but also
>>>>> weren't before.
>>>
>>> For stable: cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in
>>> SE_GENI_CLK_SEL") has already shipped in 7.2.9, 6.18.55 and 6.12.112,
>>> and is
>>> queued for 6.6, 6.1, 5.15 and 5.10.
>>>
>>> The 32 MHz clock map (506bb2ab0075, v6.13+) does not exist in 6.12.y
>>> and older.
>>> The backports there pick only the 19.2 MHz entry, so the Yoga Slim 7x /
>>> X1E80100 timing regression cannot occur on 6.12.y or older, and I'm
>>> keeping the
>>> 6.6 and older queues as they are.
>>>
>>> 7.2.y and 6.18.y do have the 32 MHz table and are affected. Once the
>>> fix lands
>>> in mainline, I'll pick it up for 7.2 and 6.18.
>>
>> @Andi, @viken, and/or @Daniel:
>>
>> Is the patch at the start of the thread or some improved version heading
>> to mainline meanwhile? What Sasha wrote above is one reason why that
>> would be good rather sooner than latter; another is a regression
>> report[1] from Birk (now CCed) wo ran into the problem with mainline --
>> so it would be good to fix this before 7.3 is released, too.
>>
>> Or is a revert the better option to achieve that?
> 
> This is in active discussion with hardware experts, but taking time to
> get specs compliant configuration values while it's being tested.

That's how it is sometimes, but then it's likely best to go back to the
know old state by reverting the culprit -- or is that a bad idea for
some reason?

> I see 7.3 release on 25th, so what max time we can have before reverting ?

Not sure where you get this from, but 7.3 most likely will be released
this Sunday, so four days from now. Given that this affects stable is
should ideally be fixed quickly anyway. And the issue is know for a
while, so it normally should be fixed already, as that's what Linus wants:

https://www.kernel.org/doc/html/latest/process/handling-regressions.html#on-how-quickly-regressions-should-be-fixed

""But if it's a regression with a known commit that caused it, I think
the rule of thumb [to fix it] should generally be "within a week",
preferably before the next rc."""

Ciao, Thorsten