Re: [PATCH] HID: ayaneo: Add AYANEO 3 detachable controller driver

["Matías Martínez" <hello@matias.me>]

Addressing the four findings for the humans on the thread — the bot
went two for four:

- The devres ordering issue is real, and understated: any brightness
  write racing a driver unbind could queue LED work that runs after
  hid_hw_stop() and after devres frees the driver data. I reproduced
  memory corruption by unbinding under a brightness-write loop, and
  the window is reachable in normal use (the controller power-cycles
  on resume and on module eject while userspace may be writing the
  LED). v2 registers the LED without devm, unregisters it first in
  remove, and flushes set_brightness_work again once the sysfs node
  is provably gone — a store can requeue it between the flush inside
  led_classdev_unregister() and the device_unregister() that follows.

- The eject-loop stall on unplug is real too. v2 aborts on fatal
  transport errors and only keeps polling on timeouts.

- The maxcollection finding is not a crash: hid_open_report()
  zero-allocates the collection array, so a descriptor with no
  collections reads usage 0 and probe returns -ENODEV. v2 adds an
  explicit maxcollection check anyway, as it states the intent
  better.

- The stale-reply race cannot cross commands: replies are matched on
  the echoed subcommand byte, so a late reply can only complete a
  retry of the same command, and those are interchangeable snapshots
  milliseconds apart. v2 documents this in aya3_raw_event().

All of the above is in v2, along with Antheas's review items.

Matías