linux-kernel - Re: [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 for Android: free password hash cracker in your pocket

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

Message-ID: <881968q8-nsqn-pso8-9979-1071r3288s74@xreary.bet>
Date: Wed, 11 Dec 2024 15:06:24 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
cc: Hans de Goede <hdegoede@...hat.com>, linux-input@...r.kernel.org, 
    linux-kernel@...r.kernel.org, Benjamin Tissoires <bentiss@...nel.org>, 
    Bryan.Kemp@...l.com, laurentiu.tudor1@...l.com
Subject: Re: [PATCH v2 0/2] HID: i2c-hid: re-power-on quirk for QTEC kbrd

On Thu, 31 Oct 2024, Aleksandrs Vinarskis wrote:

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

Applied, thanks, and sorry for the delay.

-- 
Jiri Kosina
SUSE Labs