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