HID device initiated reset and need for device reconfiguration in linux driver

HID device initiated reset and need for device reconfiguration in linux driver

[Angela Czubak]

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.

Any advice would be welcome :)

Regards,
Angela

Re: HID device initiated reset and need for device reconfiguration in linux driver

[Benjamin Tissoires]

Hi Angela,

On Mon, Mar 21, 2022 at 10:05 PM Angela Czubak <acz@semihalf.com> 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@mail.gmail.com/#r