Hi Angela, On Mon, Mar 21, 2022 at 10:05 PM Angela Czubak <acz@xxxxxxxxxxxx> wrote: > > Hi Dmitry, Hi Benjamin, > > I am wondering if there is some mechanism already present in the linux > kernel that would trigger > some (re)configration process once a (device initiated?) reset has > been detected for a HID device. > > My precise scenario is a case in which a haptic device decides to > reset itself for some reason > after it has been already probed. The default device mode is autonomous mode. > However, since I would like to add kernel support, the driver itself > would believe the device is > in manual mode, and either it would generate output reports itself or > would allow the user space > to do so. > This might result in doubled haptic feedback (from the device itself > and the kernel/user initiated one). > > I can see that in drivers/hid/i2c-hid/i2c-hid-core.c that there is a > point where we realise that a reset > has happened (interrupt handler case where response size is actually > 0). I would guess it could > be a good place to issue some callback that would trigger all > necessary reconfiguration (in my case > it would be putting the device back into manual mode). > I suppose we could add something like 'int (*reset)(struct hid_device > *hdev)' to 'struct hid_driver' > definition, then set it if applicable in a relevant hid-* driver, so > that we could issue it in case of reset, > specifically the device initiated reset. > > It does not seem a problem specific to haptic devices, so I am > wondering if that would be a good > approach, or, perhaps, there is some kind of already existing > workaround for such situations. FWIW, we already had a similar-ish discussion about that while reviewing the v1 of spi-hid [0]. Basically, it seems that spi-hid devices are seeing more of those device initiated reset, and that something needs to be done. However, in this very specific use case, all that matters was to reset the device, but nothing else was required (the device was already in the correct mode). So we decided to postpone the decision/implementation. Now, it definitely makes sense for haptics devices to be notified about such resets, because you enter in some inconsistent state. Your approach of adding a new callback to struct hid_driver is the correct one IMO, and we never implemented it until now because we never had a strong need for it. I think this only matters for I2C and SPI devices. AFAICT, USB or Bluetooth devices would simply completely remove/recreate the device in the rare cases where this happens. But the discussions around SPI makes me think that it is way more common in the I2C and SPI cases, so reconnecting the device is rather brutal. Cheers, Benjamin > > Any advice would be welcome :) > > Regards, > Angela > [0] https://lore.kernel.org/linux-input/CAO-hwJLVMK9Vh9za70uFzimXv444HC5az_1Jr4ut6BDA+XSfYA@xxxxxxxxxxxxxx/#r
