lkml.org 
[lkml]   [2022]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/12] i2c-hid: fixes for unnumbered reports and other improvements
On Mon, 17 Jan 2022, Dmitry Torokhov wrote:

> Hi,
>
> This series came about after I reviewed Angela's patch that fixed issues
> with incorrect handling of high-numbered reports (15 and above) in
> i2c-hid driver:
>
> - it appears to me that the driver did not handle unnumbered reports
> correctly as the kernel internally expects unnumbered reports to be
> still prepended with report number 0, but i2c_hid_get_raw_report() and
> i2c_hid_output_raw_report() only expected report ID to be present for
> numbered reports.
>
> - the driver tried to consolidate both command handling and sending
> output reports in __i2c_hid_command() but the rules for different
> commands vary significantly and because of that the logic was hard to
> follow and it bled out from __i2c_hid_command() to callers. I decided
> to introduce a few simple helpers and have the data encoding for
> individual commands done at the call site. I believe this made it
> easier to validate the rules and the logic and allowed to remove
> special handling for the HID descriptor retrieval, among other things.
>
> - the driver does too many copying of data; encoding the data for
> commands at the call site allowed to only copy data once into the
> transfer buffers.
>
> I tested this on a couple of Chromebooks with i2c-hid touchscreens, but
> it would be great if other folks tried it out as well.

Benjamin,

is this something you could feed into your testing machinery as well? (not
sure whether it's handling i2c-hid specifics).

Thanks!

--
Jiri Kosina
SUSE Labs

\
 
 \ /
  Last update: 2022-02-02 14:57    [W:0.171 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site