Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The commit modifies `Documentation/hid/hid-transport.rst` to state that the `output_report` callback 'might be asynchronous', which directly contradicts the strict HID subsystem architectural rule requiring it to be unconditionally asynchronous. --
--- Patch [1]: [PATCH v3 01/11] Documentation: Correction in HID output_report callback description. --- commit 5b8559748c059ec63c5c810fdf494efbd38be948 Author: Jarrett Schultz <[email protected]> Documentation: Correction in HID output_report callback description. This commit modifies the HID transport documentation to indicate that the output_report callback might be asynchronous rather than strictly requiring it to be asynchronous. It notes that some implementations, like i2c-hid, do not implement it asynchronously. > 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] This isn't a bug, but does this documentation change conflict with the subsystem's architectural guidelines? The official HID subsystem guidelines explicitly state that the output_report callback (used for high-throughput data on the interrupt channel) must be asynchronous and must not trigger synchronous SET_REPORT calls. Relaxing this language to "might be asynchronous" contradicts the strict architectural rule and might encourage future driver implementations that block or perform synchronous operations. Should the documentation continue to mandate the asynchronous requirement to prevent synchronous blocking on the interrupt channel? > > :: > -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
