Re: [PATCH v3 01/11] Documentation: Correction in HID output_report callback description.

[sashiko-bot@kernel.org]

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 <jaschultz@microsoft.com>

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/20260402-send-upstream-v3-0-6091c458d357@chromium.org?part=1