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

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

[Daniel J Blueman]

Commit cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in
SE_GENI_CLK_SEL") allowed GENI to use 32MHz clock. This changed I2C
timing, making the Yoga Slim 7x keyboard (ITE 048D:8987) unusable
on all boots, and touchpad unusable on some boots, resulting in:

  i2c_hid_of 1-003a: unexpected HID descriptor bcdVersion (0x0000)
  i2c_hid_of 1-002c: failed to fetch HID descriptor: -110

With this change, t_high_cnt 3 and clk_div 4 gave a tSCL of 375ns
versus the previous default of 521ns, however the I2C spec has a
minimum tSCL of 600ns.

Restore tSCL to the spec with t_high_cnt 5 giving a 625ns tSCL,
verified on Lenovo Yoga Slim 7x X1E-80100.

Fixes: 506bb2ab0075 ("i2c: qcom-geni: Support systems with 32MHz serial engine clock")
Cc: <stable@vger.kernel.org>
Signed-off-by: Daniel J Blueman <daniel@quora.org>
---
 drivers/i2c/busses/i2c-qcom-geni.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
index 6a39e21d5ed4..1336a09ca183 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -193,7 +193,7 @@ static const struct geni_i2c_clk_fld geni_i2c_clk_map_19p2mhz[] = {
 /* source_clock = 32 MHz */
 static const struct geni_i2c_clk_fld geni_i2c_clk_map_32mhz[] = {
 	{ I2C_MAX_STANDARD_MODE_FREQ, 12, 9, 10, 26 },
-	{ I2C_MAX_FAST_MODE_FREQ, 4, 3, 9, 19 },
+	{ I2C_MAX_FAST_MODE_FREQ, 4, 5, 9, 19 },
 	{ I2C_MAX_FAST_MODE_PLUS_FREQ, 2, 3, 5, 15 },
 	{}
 };
-- 
2.53.0

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

[Mukesh Savaliya]

Thanks Daniel !

On 9/29/2026 9:44 AM, Daniel J Blueman wrote:
> Commit cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in
> SE_GENI_CLK_SEL") allowed GENI to use 32MHz clock. This changed I2C
> timing, making the Yoga Slim 7x keyboard (ITE 048D:8987) unusable
> on all boots, and touchpad unusable on some boots, resulting in:
> 
>    i2c_hid_of 1-003a: unexpected HID descriptor bcdVersion (0x0000)
>    i2c_hid_of 1-002c: failed to fetch HID descriptor: -110
> 
> With this change, t_high_cnt 3 and clk_div 4 gave a tSCL of 375ns
> versus the previous default of 521ns, however the I2C spec has a
> minimum tSCL of 600ns.
> 
> Restore tSCL to the spec with t_high_cnt 5 giving a 625ns tSCL,
> verified on Lenovo Yoga Slim 7x X1E-80100.
> 

There might be a final count which i should get and update back.
Since this fix is working though not suggested per hardware guidance, 
should we consider as temporary fix and move ahead to prevent failing 
usecase ?

Any thought @andi ?

> Fixes: 506bb2ab0075 ("i2c: qcom-geni: Support systems with 32MHz serial engine clock")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> ---
>   drivers/i2c/busses/i2c-qcom-geni.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
> index 6a39e21d5ed4..1336a09ca183 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -193,7 +193,7 @@ static const struct geni_i2c_clk_fld geni_i2c_clk_map_19p2mhz[] = {
>   /* source_clock = 32 MHz */
>   static const struct geni_i2c_clk_fld geni_i2c_clk_map_32mhz[] = {
>   	{ I2C_MAX_STANDARD_MODE_FREQ, 12, 9, 10, 26 },
> -	{ I2C_MAX_FAST_MODE_FREQ, 4, 3, 9, 19 },
> +	{ I2C_MAX_FAST_MODE_FREQ, 4, 5, 9, 19 },

Exact change to come from hardware experts, till that i am hoping this 
revert should be fine.

>   	{ I2C_MAX_FAST_MODE_PLUS_FREQ, 2, 3, 5, 15 },
>   	{}
>   };

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

[Daniel J Blueman]

On Wed, 30 Sept 2026 at 15:19, Mukesh Savaliya
<mukesh.savaliya@oss.qualcomm.com> wrote:
>
> Thanks Daniel !
>
> On 9/29/2026 9:44 AM, Daniel J Blueman wrote:
> > Commit cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in
> > SE_GENI_CLK_SEL") allowed GENI to use 32MHz clock. This changed I2C
> > timing, making the Yoga Slim 7x keyboard (ITE 048D:8987) unusable
> > on all boots, and touchpad unusable on some boots, resulting in:
> >
> >    i2c_hid_of 1-003a: unexpected HID descriptor bcdVersion (0x0000)
> >    i2c_hid_of 1-002c: failed to fetch HID descriptor: -110
> >
> > With this change, t_high_cnt 3 and clk_div 4 gave a tSCL of 375ns
> > versus the previous default of 521ns, however the I2C spec has a
> > minimum tSCL of 600ns.
> >
> > Restore tSCL to the spec with t_high_cnt 5 giving a 625ns tSCL,
> > verified on Lenovo Yoga Slim 7x X1E-80100.
> >
>
> There might be a final count which i should get and update back.
> Since this fix is working though not suggested per hardware guidance,
> should we consider as temporary fix and move ahead to prevent failing
> usecase ?

If you can get the final values into a patch for the next -rc instead
of my fix here, that would be the minimal path for everyone. You or
the hardware team can cross-check against the I2C standard as I did
[1, p44].

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.

Thanks,
  Dan

-- [1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf
-- 
Daniel J Blueman

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

[Mukesh Savaliya]

Thanks Dan !

On 9/30/2026 3:01 PM, Daniel J Blueman wrote:
> On Wed, 30 Sept 2026 at 15:19, Mukesh Savaliya
> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>
>> Thanks Daniel !
>>
>> On 9/29/2026 9:44 AM, Daniel J Blueman wrote:
>>> Commit cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in
>>> SE_GENI_CLK_SEL") allowed GENI to use 32MHz clock. This changed I2C
>>> timing, making the Yoga Slim 7x keyboard (ITE 048D:8987) unusable
>>> on all boots, and touchpad unusable on some boots, resulting in:
>>>
>>>     i2c_hid_of 1-003a: unexpected HID descriptor bcdVersion (0x0000)
>>>     i2c_hid_of 1-002c: failed to fetch HID descriptor: -110
>>>
>>> With this change, t_high_cnt 3 and clk_div 4 gave a tSCL of 375ns
>>> versus the previous default of 521ns, however the I2C spec has a
>>> minimum tSCL of 600ns.
>>>
>>> Restore tSCL to the spec with t_high_cnt 5 giving a 625ns tSCL,
>>> verified on Lenovo Yoga Slim 7x X1E-80100.
>>>
>>
>> There might be a final count which i should get and update back.
>> Since this fix is working though not suggested per hardware guidance,
>> should we consider as temporary fix and move ahead to prevent failing
>> usecase ?
> 
> If you can get the final values into a patch for the next -rc instead
> of my fix here, that would be the minimal path for everyone. You or
> the hardware team can cross-check against the I2C standard as I did
> [1, p44].
> 

Yes, Agree Dan ! That would be quick and fast way.
I am in discussion to get more details on correct configuration meeting 
the specs.

> 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.
> 
Agree, after having last change thought that would meet the spec.


> Thanks,
>    Dan
> 
> -- [1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf

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

[Sasha Levin]

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

-- 
Thanks,
Sasha

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

[Birk Skyum]

On Tue, 29 Sep 2026 12:14:43 +0800, Daniel J Blueman wrote:
> With this change, t_high_cnt 3 and clk_div 4 gave a tSCL of 375ns
> versus the previous default of 521ns, however the I2C spec has a
> minimum tSCL of 600ns.
>
> Restore tSCL to the spec with t_high_cnt 5 giving a 625ns tSCL,
> verified on Lenovo Yoga Slim 7x X1E-80100.

This fixes it on another Yoga Slim 7x (83ED).

I took a distribution build of 7.2.8 that works on this laptop and
replaced only i2c-qcom-geni.ko, built from the same tree:

  7.2.8 driver                   keyboard works
  7.2.9 driver                   keyboard and touchpad dead
  7.2.9 driver with this patch   keyboard, touchpad, touchscreen work

With the patch the keyboard takes the disk passphrase in the initramfs
again. The five I2C controllers in use run from the 32 MHz clock, as
they do without it, and the log has no error from geni_i2c or
i2c_hid_of. That is one boot.

Tested-by: Birk Skyum <birk.skyum@pm.me> # Lenovo Yoga Slim 7x

Thanks,
Birk

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

[Thorsten Leemhuis]

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?

Ciao, Thorsten

[1]
https://lore.kernel.org/stable/179173732257.29426.7905170638383807320@pm.me/