linux-kernel - [PATCH v2 0/2] HID: i2c-hid: re-power-on quirk for QTEC kbrd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241031073419.9189-1-alex.vinarskis@gmail.com>
Date: Thu, 31 Oct 2024 08:31:40 +0100
From: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
To: Jiri Kosina <jikos@...nel.org>,
	Hans de Goede <hdegoede@...hat.com>,
	linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Cc: Benjamin Tissoires <bentiss@...nel.org>,
	Bryan.Kemp@...l.com,
	laurentiu.tudor1@...l.com,
	Aleksandrs Vinarskis <alex.vinarskis@...il.com>
Subject: [PATCH v2 0/2] HID: i2c-hid: re-power-on quirk for QTEC kbrd

Resolve keyboard not working out of the box for Dell XPS 9345 13"
codenamed 'tributo'. X1E80100-based laptop's initial support is currently
being upstreamed [1].

In present state, keyboard is succesfully initialized, however attempt to type
anything throws 'incomplete report' errors. When utilizing
I2C_HID_QUIRK_BAD_INPUT_SIZE quirk the error is gone, however raw data coming
from the keyboard is always the same, no matter the key pressed. Issue
'resolves' itself when suspending and resuming the device.

It appears that calling power on command one more time after device
initialization before finishing off the probing fixes this weird behavior, and
keyboard works right away.

Introduce a new quirk for such behaviour, and enable it for particular keyboard.
Vendor is shown as 'QTEC', however device id is reported as 0000. Given that
vendor was not present before, using HID_ANY_ID to match the device should be
okay in this case.

In v1 it was suggested to make a dedicated i2c-of-qtec driver, but I was not
sure how to proceed at the time. I have now drafted a dedicated driver, and it
really is just probe method being extended to call powerup command again. Given
that a similarly 'ugly' quirk was just merged to i2c-hid-core.c for a Goodix
device [2], and that (IMO) creating a dedicated driver for such a small change
without any plan on extending it will be just polluting, I am asking you to
consider this change again. Alternatively, if it is yet still strongly
preferred to have a dedicated driver to include this quirk, please let me know
so I can proceed accordingly.

[1] https://lore.kernel.org/all/20241003211139.9296-1-alex.vinarskis@gmail.com/
[2] https://lore.kernel.org/all/20241007222629.172047-1-marynczakbartlomiej@gmail.com/

--------

Changes to V1:
* Rebase on top of latest linux-next
* Update coverletter's reasoning and links
* link: https://lore.kernel.org/all/20240925100303.9112-1-alex.vinarskis@gmail.com/

Aleksandrs Vinarskis (2):
  HID: i2c-hid: introduce re-power-on quirk
  HID: i2c-hid: introduce qtec vendor, enable re-power-on quirk

 drivers/hid/hid-ids.h              |  2 ++
 drivers/hid/i2c-hid/i2c-hid-core.c | 12 +++++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

-- 
2.45.2