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-prev] [day] [month] [year] [list]
Message-ID:
 <CY5PR19MB614758F6060B4B07D06158D0BA552@CY5PR19MB6147.namprd19.prod.outlook.com>
Date: Thu, 31 Oct 2024 16:26:56 +0000
From: "Tudor, Laurentiu" <Laurentiu.Tudor1@...l.com>
To: Aleksandrs Vinarskis <alex.vinarskis@...il.com>,
        Jiri Kosina
	<jikos@...nel.org>, Hans de Goede <hdegoede@...hat.com>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Benjamin Tissoires <bentiss@...nel.org>,
        "Kemp, Bryan"
	<Bryan.Kemp@...l.com>
Subject: RE: [PATCH v2 0/2] HID: i2c-hid: re-power-on quirk for QTEC kbrd




Internal Use - Confidential
> -----Original Message-----
> From: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
> Sent: Thursday, October 31, 2024 9:32 AM
>
> 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.
>
> --------

For the series:

Reviewed-by: Laurentiu Tudor <Laurentiu.Tudor1@...l.com>
Tested-by: Laurentiu Tudor <Laurentiu.Tudor1@...l.com>

---
Thanks & Best Regards, Laurentiu

> Changes to V1:
> * Rebase on top of latest linux-next
> * Update coverletter's reasoning and links
> * link:
> https://urldefense.com/v3/__https://lore.kernel.org/all/20240925100303.911
> 2-1-
> alex.vinarskis@...il.com/__;!!LpKI!hTYUmNdAbx06nnU3DlrMQn9PGzi4y9Ne
> SOTjPf2SPO67ore1XymZjywoQN19RvKaVHbNs5VLc9_77mwvQAT8em7dODeJ
> $ [lore[.]kernel[.]org]
>
> 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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ