Skip to content
  1. Oct 14, 2023
  3. Oct 13, 2023
  5. Oct 04, 2023
    • Hans de Goede's avatar
      Input: goodix - ensure int GPIO is in input for gpio_count == 1 && gpio_int_idx == 0 case · 423622a9
      Hans de Goede authored 
      Add a special case for gpio_count == 1 && gpio_int_idx == 0 to
goodix_add_acpi_gpio_mappings().

It seems that on newer x86/ACPI devices the reset and irq GPIOs are no
longer listed as GPIO resources instead there is only 1 GpioInt resource
and _PS0 does the whole reset sequence for us.

This means that we must call acpi_device_fix_up_power() on these devices
to ensure that the chip is reset before we try to use it.

This part was already fixed in commit 3de93e6e

 ("Input: goodix - call
acpi_device_fix_up_power() in some cases") by adding a call to
acpi_device_fix_up_power() to the generic "Unexpected ACPI resources"
catch all.

But it turns out that this case on some hw needs some more special
handling. Specifically the firmware may bootup with the IRQ pin in
output mode. The reset sequence from ACPI _PS0 (executed by
acpi_device_fix_up_power()) should put the pin in input mode,
but the GPIO subsystem has cached the direction at bootup, causing
request_irq() to fail due to gpiochip_lock_as_irq() failure:

[    9.119864] Goodix-TS i2c-GDIX1002:00: Unexpected ACPI resources: gpio_count 1, gpio_int_idx 0
[    9.317443] Goodix-TS i2c-GDIX1002:00: ID 911, version: 1060
[    9.321902] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-5/i2c-GDIX1002:00/input/input8
[    9.327840] gpio gpiochip0: (INT3453:00): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ
[    9.327856] gpio gpiochip0: (INT3453:00): unable to lock HW IRQ 26 for IRQ
[    9.327861] genirq: Failed to request resources for GDIX1002:00 (irq 131) on irqchip intel-gpio
[    9.327912] Goodix-TS i2c-GDIX1002:00: request IRQ failed: -5

Fix this by adding a special case for gpio_count == 1 && gpio_int_idx == 0
which adds an ACPI GPIO lookup table for the int GPIO even though we cannot
use it for reset purposes (as there is no reset GPIO).

Adding the lookup will make the gpiod_int = gpiod_get(..., GPIOD_IN) call
succeed, which will explicitly set the direction to input fixing the issue.

Note this re-uses the acpi_goodix_int_first_gpios[] lookup table, since
there is only 1 GPIO in the ACPI resources the reset entry in that
lookup table will amount to a no-op.

Reported-and-tested-by: default avatarMichael Smith <1973.mjsmith@gmail.com>
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20231003215144.69527-1-hdegoede@redhat.com


Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      423622a9
    • Szilard Fabian's avatar
      Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table · 80f39e1c
      Szilard Fabian authored 
      

In the initial boot stage the integrated keyboard of Fujitsu Lifebook E5411
refuses to work and it's not possible to type for example a dm-crypt
passphrase without the help of an external keyboard.

i8042.nomux kernel parameter resolves this issue but using that a PS/2
mouse is detected. This input device is unused even when the i2c-hid-acpi
kernel module is blacklisted making the integrated ELAN touchpad
(04F3:308A) not working at all.

Since the integrated touchpad is managed by the i2c_designware input
driver in the Linux kernel and you can't find a PS/2 mouse port on the
computer I think it's safe to not use the PS/2 mouse port at all.

Signed-off-by: default avatarSzilard Fabian <szfabian@bluemarch.art>
Link: https://lore.kernel.org/r/20231004011749.101789-1-szfabian@bluemarch.art


Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      80f39e1c
  7. Sep 18, 2023
  9. Aug 31, 2023
  11. Aug 16, 2023
  13. Aug 02, 2023
  15. Jul 29, 2023
  17. Jul 26, 2023
    • Jeffery Miller's avatar
      Input: psmouse - add delay when deactivating for SMBus mode · 92e24e0e
      Jeffery Miller authored 
      There is a period of time between the psmouse deactivate and the
ability to communicate with the SMBus companion. Insert a
sleep after the deactivate to account for the delay and ensure
the SMBus companion is responsive.

Attempting to read from the SMBus companion too quickly was causing
the touchpad on machines with an i801_smbus companion to stop working
after a sleep/resume cycle.

On resume the rmi4_smbus would fail with errors reading the SMBus version
number:
```
[5454] i2c_i801:i801_check_post:414: i801_smbus 0000:00:1f.3: No response
smbus_result: i2c-0 a=02c f=0000 c=fd BYTE_DATA rd res=-6
rmi4_smbus 0-002c: failed to get SMBus version number!
...
rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -6.
rmi4_f01 rmi4-00.fn01: Resume failed with code -6.
rmi4_physical rmi4-00: Failed to suspend functions: -6
rmi4_smbus 0-002c: Failed to resume device: -6
```
In this case the rmi_smb_get_version fails with -ENXIO if it happens too
soon after the preceding serio_resume -> psmouse_deactivate call.

On boot this issue could cause the touchpad to stay in the limited PS/2
mode. This only reproduced in 1 in 10 boots on the Lenovo T440p.
Failures in the log on boot would show up as:
```
psmouse serio1: synaptics: Trying to set up SMBus access
[122] i2c_i801:i801_check_post:437: i801_smbus 0000:00:1f.3: No response
psmouse serio1: synaptics: SMbus companion is not ready yet
```

Experimentation on the Lenovo T440p showed that a delay of 7-12ms on
resume allowed the companion to respond.

The 30ms delay in this patch was chosen based on the linux-input message:
Link: https://lore.kernel.org/all/BYAPR03MB47572F2C65E52ED673238D41B2439@BYAPR03MB4757.namprd03.prod.outlook.com/



Signed-off-by: default avatarJeffery Miller <jefferymiller@google.com>
Link: https://lore.kernel.org/r/20230726025256.81174-1-jefferymiller@google.com


Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      92e24e0e
    • Nathan Chancellor's avatar
      Input: mcs-touchkey - fix uninitialized use of error in mcs_touchkey_probe() · 8362bf82
      Nathan Chancellor authored 
      Clang warns (or errors with CONFIG_WERROR=y):

  drivers/input/keyboard/mcs_touchkey.c:149:49: error: variable 'error' is uninitialized when used here [-Werror,-Wuninitialized]
    149 |                 dev_err(&client->dev, "i2c read error[%d]\n", error);
        |                                                               ^~~~~
  include/linux/dev_printk.h:144:65: note: expanded from macro 'dev_err'
    144 |         dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
        |                                                                        ^~~~~~~~~~~
  include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
    110 |                 _p_func(dev, fmt, ##__VA_ARGS__);                       \
        |                                     ^~~~~~~~~~~
  drivers/input/keyboard/mcs_touchkey.c:110:11: note: initialize the variable 'error' to silence this warning
    110 |         int error;
        |                  ^
        |                   = 0
  1 error generated.

A refactoring updated the error handling in this block but did not
update the dev_err() call to use fw_ver instead of error. Do so now to
fix the warning and avoid printing uninitialized memory.

Closes: https://github.com/ClangBuiltLinux/linux/issues/1893
Fixes: e175eae1

 ("Input: mcs-touchkey - convert to use devm_* api")
Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20230725-mcs_touchkey-fix-wuninitialized-v1-1-615db39af51c@kernel.org


Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      8362bf82
  19. Jul 21, 2023
  21. Jul 19, 2023
  23. Jul 18, 2023
  25. Jul 14, 2023
  27. Jul 13, 2023
  29. Jul 11, 2023