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
