Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 2 Feb 2022 14:56:32 +0100 (CET)
From:   Jiri Kosina <jikos@kernel.org>
To:     Dmitry Torokhov <dmitry.torokhov@gmail.com>
cc:     Benjamin Tissoires <benjamin.tissoires@redhat.com>,
        Angela Czubak <acz@semihalf.com>, linux-input@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/12] i2c-hid: fixes for unnumbered reports and other
 improvements
In-Reply-To: <20220118072628.1617172-1-dmitry.torokhov@gmail.com>
Message-ID: <nycvar.YFH.7.76.2202021456020.11721@cbobk.fhfr.pm>
References: <20220118072628.1617172-1-dmitry.torokhov@gmail.com>
User-Agent: Alpine 2.21 (LSU 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

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