Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] hid: documentation incorrectly relaxes asynchronous requirement for output_report --
commit 6d8fa62fc058c7f5630a13cc92c85b7867bc9869 Author: Jarrett Schultz <[email protected]> Documentation: Correction in HID output_report callback description. This commit updates the documentation for the HID output_report callback. It changes the description to state that the callback might be asynchronous rather than strictly requiring it, citing i2c-hid as an example. > diff --git a/Documentation/hid/hid-transport.rst > b/Documentation/hid/hid-transport.rst > index 6f1692da296cf..2008cf432af12 100644 > --- a/Documentation/hid/hid-transport.rst > +++ b/Documentation/hid/hid-transport.rst > @@ -327,8 +327,8 @@ The available HID callbacks are: > > Send raw output report via intr channel. Used by some HID device drivers > which require high throughput for outgoing requests on the intr channel. > This > - must not cause SET_REPORT calls! This must be implemented as asynchronous > - output report on the intr channel! > + must not cause SET_REPORT calls! This call might be asynchronous, so the > + caller should not expect an immediate response! [Severity: Medium] Does this documentation change contradict the strict architectural guarantees of the HID subsystem? The HID subsystem design rules mandate that the output_report callback must be asynchronous to prevent latency spikes, performance degradation, or deadlocks on the high-throughput interrupt channel. By stating that the call "might be asynchronous", could this inadvertently mislead future transport driver authors into implementing blocking, synchronous callbacks where they are not permitted? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
