Re: i2c designware change broke touchpad of a thinkpad

On 8/17/26 11:51, [email protected] wrote:
> On 14-Aug-26 12:09 PM, Hardik Prakash wrote:
>> On Wed, 13 Aug 2026, Thorsten Leemhuis wrote:
>>> Hardik, could you submit a revert to the lists? And then I'll provide my
>>> Tested-by and ask Linus to directly pick this up?
>>
>> Sent: https://lore.kernel.org/all/[email protected]/
>>
>> Verified on my end that it builds clean, boots clean, and correctly
>> restores the original Yoga 7 race (expected tradeoff) without
>> introducing anything else.

Hans, thx for looking into this.
> Thank you for submitting a revert for this. Note it looks like Torvalds himself
> beat you to it and already reverted this for 7.2 final :)

Yeah, I pointed Linus to this and a few others issues and then he
reverted the change directly:
https://lore.kernel.org/all/[email protected]/

> I hit another problem caused by this now reverted change, where the PMIC
> i2c bus would not show up on many Intel BYT/CHT devices. I wrote a fix for
> this (attached) on top of the now reverted commit.

FWIW, meanwhile "Tran Tien Dat" (now CCed) with -next ran into a problem
on a MSI Modern 14 H D13MG that the revert seems to have resolved. But
the symptoms were different: the two DesignWare I2C controllers in that
machine apparently deferred probe forever and are never retried:

16.429266 platform i2c_designware.1: deferred probe pending: (reason
unknown)
16.429286 platform i2c_designware.0: deferred probe pending: (reason
unknown)

For details, see: https://bugzilla.kernel.org/show_bug.cgi?id=221889

Ciao, Thorsten

> I think my fix might also have helped for the broken touchpad issue from this
> thread, but I believe there is a better way to fix all this, so IMHO it is
> good that this was reverted.
> 
> If I understand things correctly the problem the reverted fix was trying
> to fix is i2c-transfer errors happening before the GPIO controller driver
> is ready.
> 
> The i2c-core will not initiate transfers itself, so the problem is that
> the i2c-hid driver is initiating transfers before the GPIO controller
> is setup.
> 
> The i2c-hid driver does actually request the interrupt itself, so we can
> simply wait for that to succeed inside the i2c-hid code. ATM the i2c-hid
> code starts with an i2c-connectivity check because some ACPI tables list
> non existing I2C-HID devices.
> 
> But we could make the i2c-hid driver start with first requesting its IRQ
> and if that fails bail (with -EPROBE_DEFER) before doing any i2c-transfers.
> 
> And then do the i2c-connectivity test after requesting the IRQ. So basically
> swap the order of i2c-connectivity test vs IRQ requesting.
> 
> The IRQ requesting should then use the IRQF_NO_AUTOEN flag to keep the IRQ
> disabled at first and explicitly enable it later when the rest of the driver
> setup is done.
> 
> Hardik, can you take a shot at coding up the suggested i2c-hid(-core) changes
> and test to see if this fixes the original Yoga 7 race in a cleaner manner ?
> 
> Regards,
> 
> Hans
>