On Wed, 11 Sep 2024, Dmitry Torokhov wrote: > > > i2c-hid uses 2 shared buffers: command and "raw" input buffer for > > > sending requests to peripherals and read data from peripherals when > > > executing variety of commands. Such commands include reading of HID > > > registers, requesting particular power mode, getting and setting > > > reports and so on. Because all such requests use the same 2 buffers > > > they should not execute simultaneously. > > > > > > Fix this by introducing "cmd_lock" mutex and acquire it whenever > > > we needs to access ihid->cmdbuf or idid->rawbuf. > > > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > > > > Thanks for the fix, Dmitry. Out of curiosity, did you find it by code > > inspection, or have you actually seen it happening for real, making the > > driver misbehave? > > No, I have not observed this issue in the wild, that is why I di dnot > tag it explicitly for stable. Thanks. I was asking whether I should rush it in still for 6.11, or whether waiting for 6.12 merge window is sufficient. So I will send it to Linus for 6.12, but I still think tagging for stable should probably be done. > It came about when I was reviewing Goodix HID SPI driver, noticed that > it was using a shared buffer, asked to and locking, and realized that > I2C HID needed the same. And just got around to sending out the fix... > > As far as I can see USB HID driver does not need it - it does not share > URBs but rather allocates new one for each request (via > usb_control_msg()). Indeed, USB HID is fine in that respect. Thanks a lot, -- Jiri Kosina SUSE Labs
